I suggest to evaluate $title->userCan() on the current page, and pass it as a JS config variable (perhaps userCanEdit) to the PropertyEditTool. If userCanEdit is false, the edit functionality should be disable for the page.
Note that we can not suppress the edit features in the output of ItemView, because that gets shared between different users via the parser cache.
Version: master
Severity: major
Whiteboard: storypoints: 8
Setting this to critical, because inadvertently editing old revisions leads to data loss.
To reiterate the issue:
If the current user is not (or should not be) able to edit the item revision that is currently shown, the UI should not present edit functionality. There are three cases where this is true:
Reasons 2 and 3 are covered by Title::userCan( 'edit' ), and I hope there's already a javascript variable that conveys the same information. If not, we'll have to create one.
Reason 1 should hopefully also be detected easily from JavaScript.
Implementation note: In the past, the loading of the Wikibase JS modules was supressed for old revisions and if the user wasn't allowed to edit. This should NOT be the case. Instead, the modules should always be loaded, but should only show editing tools if editing is possible and desired.
mw.config:
(In reply to comment #2)
mw.config:
- wgRestrictionEdit (undefined || Array of user groups)
- wgRestrictionMove (undefined || Array of user groups)
- wgUserGroups (Array of user groups)
Hm, that'S not terribky useful... wouldn't it be nice to have the result of Title::userCan("edit") readily available in JS? There's no way to determine this from JS alone, with all the hooks being called.
Lots of things would be nice, but this is what is available now and what most gadgets use.
I'd recommend proposing in MediaWiki core an array to javascript with allowed actions on this page.