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.
Version: unspecified
Severity: enhancement
ste.coda wrote:
Patch
Tested patch attached.
attachment bug18677.patch ignored as obsolete
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.
matthew.britton wrote:
(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?
ste.coda wrote:
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.
sumanah wrote:
Comment on attachment 6088
Patch
Marking as obsolete given reversion in comment #4. Thank you for your suggestion, though!