Last modified: 2012-12-13 11:17:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T39987, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 37987 - Hide edit tools if the user can't edit
Hide edit tools if the user can't edit
Status: VERIFIED FIXED
Product: MediaWiki extensions
Classification: Unclassified
WikidataRepo (Other open bugs)
master
All All
: High major (vote)
: ---
Assigned To: Wikidata bugs
storypoints: 8
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-27 16:05 UTC by Daniel Kinzler
Modified: 2012-12-13 11:17 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Daniel Kinzler 2012-06-27 16:05:49 UTC
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.
Comment 1 Daniel Kinzler 2012-07-26 14:07:01 UTC
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:

1) the revision shown is not the current one
2) the user is blocked
3) the user has insufficient privileges (possibly because the page is protected, or because editing in general is somehow restricted)

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.
Comment 2 Krinkle 2012-07-31 18:20:47 UTC
mw.config:
* wgRestrictionEdit (undefined || Array of user groups)
* wgRestrictionMove (undefined || Array of user groups)
* wgUserGroups (Array of user groups)
Comment 3 Daniel Kinzler 2012-07-31 19:49:55 UTC
(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.
Comment 4 Krinkle 2012-07-31 22:38:14 UTC
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.
Comment 5 Anja Jentzsch 2012-11-29 12:38:35 UTC
Verified in Wikidata demo time for sprint 12

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links