Last modified: 2014-09-24 01:28:58 UTC
For consistency, &action=protect and &action=unprotect should give "permission denied" errors and not show the interface if the user doesn't have appropriate permissions. This is the way &action=delete and Special:MovePage work.
Created attachment 6088 [details] Patch Tested patch attached.
Patch applied in r50180
IMO this is a regression, not a bug fix. We've removed useful functionality and replaced it with an error message.
(In reply to comment #3) > IMO this is a regression, not a bug fix. We've removed useful functionality and > replaced it with an error message. > Patch reverted in r50420. WONTFIXing per the comment above.
(In reply to comment #3) > IMO this is a regression, not a bug fix. We've removed useful functionality and > replaced it with an error message. What "useful functionality" has been removed? Protection settings are in the protection log, and at the top of the page when you try to edit it. If this is the standard why aren't the block/delete/user rights pages available to all users too?
IMO if the protection settings must be shown to all users then it would have also be shown the 'Protect' button in the top of the page, otherwise only the users who know the command 'action=protect' can see the settings.
Note that we nearly always show a read-only version of information in forms of this sort, including edit, protection, and various special pages and extensions. There's no reason to remove that functionality, as it would be a regression of functionality and usability with no corresponding gain.
Re-opening this for further consideration. There's a lot of inconsistent behavior here. Some forms show permission errors, other forms show read-only or greyed-out versions of the form. This change was reverted due to bug 18728 ("Non-admins can no longer to see page protection settings"), however bug 18728 is kind of a red herring. No reasonable user would know to look for the protection settings under an invisible tab (the protect tab doesn't show to users without the 'protect' user right). Advanced users have been appending ?action=protect to get the current page protection status, but this is just a symptom of very poor UI. The real issue behind bug 18728 was that page protection status is not exposed properly in the MediaWiki UI. I've filed bug 38536 just now ("Add page protection status to MediaWiki's info action"). The general inconsistent behavior of forms when the user doesn't have the appropriate permissions still needs study and consideration.
Comment on attachment 6088 [details] Patch Marking as obsolete given reversion in comment #4. Thank you for your suggestion, though!
[Removing "easy" as the approach to fix is not clear. Also see comment 8.]
