Last modified: 2007-06-26 04:08:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6711 - More modular userrights interface
More modular userrights interface
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Aryeh Gregor (not reading bugmail, please e-mail directly)
: patch, patch-need-review
Depends on:
Blocks: 3317 6670 9862
  Show dependency treegraph
 
Reported: 2006-07-17 04:35 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2007-06-26 04:08 UTC (History)
2 users (show)

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


Attachments
Proposed patch (6.66 KB, patch)
2006-12-25 06:32 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
Proposed patch Mk II (6.30 KB, patch)
2007-05-10 03:07 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
Proposed fix (7.27 KB, patch)
2007-06-21 20:51 UTC, Max Semenik
Details

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-17 04:35:25 UTC
Ideas like this have been bandied about for quite some time, but I didn't see
any bugs open for it, so:

Often wikis will want custom groups.  Unfortunately, these groups cannot
currently be assigned easily.  Extensions have been created to allow bureaucrats
to assign and remove certain privileges, but there's no generalized way to allow
them to give and remove specific groups.

The ideal would be that in $wgGroupPermissions, the 'userrights' permission
would be changed to an array, so you could set something like
$wgGroupPermissions['bureaucrat']['userrights']['sysop']['add'] = true;.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-15 14:56:54 UTC
Better syntax would probably be

$wgGroupPermissions['bureaucrat']['addgroup']['sysop'] = true;
Comment 2 Rotem Liss 2006-08-15 15:00:25 UTC
I'm not sure if this syntax is possible, but I've proposed another syntax,
please see http://mail.wikipedia.org/pipermail/wikitech-l/2006-August/037892.html .
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-25 06:32:51 UTC
Created attachment 2950 [details]
Proposed patch

Proposed patch.  Please comment.  Uses the format I suggested originally,
except I swapped things so it's
$wgGroupPermissions['bureaucrat']['userrights']['add']['sysop'].  Maybe the
member functions should have been public User functions, but I don't know if
anything but SpecialUserrights will actually ever use them.

Tested it and it appears to work.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-25 06:35:10 UTC
It occurs to me that I didn't consider the whole "remote" aspect, though.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-10 03:00:49 UTC
Heh, always fun to look at patches you wrote yourself six months ago.  The usage
of $wgGroupPermissions seems odd, but with our SpecialPage permissions it seems
to be the only way to get it to work without either greatly generalizing the
SpecialPage permissions mechanism or writing a whole bunch of duplicate
special-case code for Userrights.
Comment 6 Titoxd 2007-05-10 03:04:46 UTC
Or make a new specialized array?
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-10 03:07:42 UTC
Created attachment 3611 [details]
Proposed patch Mk II

Updated version of previous patch.  Still needs: error messages for failures;
informative lists of what you can add and why.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-10 03:12:42 UTC
(In reply to comment #6)
> Or make a new specialized array?

Users will still need $wgGroupPermissions['userrights'] = something equivalent
to true to be able to access the page at all due to the way we do SpecialPage
restrictions.  But to maintain reverse compatibility,
$wgGroupPermissions['userrights'] = true *must* continue to mean "you're
Superman and can do anything you want".  So one way or another, this will
require either a reworking of SpecialPage permissions or a non-Boolean value in
$wgGroupPermissions.
Comment 9 Titoxd 2007-05-10 03:16:48 UTC
Well, you can always keep $wgGroupPermissions['userrights'] = true and define a
new array in DefaultSettings.php for limited permissions. If you have only the
userrights permission, you have access to everything; if you have
$wgGroupPermissions['limiteduserrights'], you go through the permissions in the
separate array.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-10 03:18:15 UTC
Hmm.  Of course, silly me.  I should have thought of that.  Yes, I (or someone
else) should update it to do that.  It's only a few lines.
Comment 11 Max Semenik 2007-06-21 20:51:44 UTC
Created attachment 3806 [details]
Proposed fix

Here is my variant for this. It makes everything customizable. For backward compatibility, Makesysop still needs to be enabled on Wikimedia wikis (integrating MakesysopStewardForm functionality into UserrightsForm would be the second step).
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-26 01:56:27 UTC
What advantages/disadvantages does that have over mine?  And why does Makesysop still need to be enabled?
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-26 04:08:13 UTC
Added in r23410.

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


Navigation
Links