More modular userrights interface
Closed, ResolvedPublic


Author: ayg

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;.

Version: unspecified
Severity: enhancement

bzimport set Reference to bz6711.
bzimport created this task.Jul 17 2006, 4:35 AM

ayg wrote:

Better syntax would probably be

$wgGroupPermissions['bureaucrat']['addgroup']['sysop'] = true;

rotemliss wrote:

I'm not sure if this syntax is possible, but I've proposed another syntax,
please see .

ayg wrote:

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.

attachment 6711.patch ignored as obsolete

ayg wrote:

It occurs to me that I didn't consider the whole "remote" aspect, though.

ayg wrote:

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.

titoxd.wikimedia wrote:

Or make a new specialized array?

ayg wrote:

Proposed patch Mk II

Updated version of previous patch. Still needs: error messages for failures;
informative lists of what you can add and why.

Attached: 6711b.patch

ayg wrote:

(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

titoxd.wikimedia wrote:

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.

ayg wrote:

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.

Created attachment 3806
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).

Attached: userrights1.patch

ayg wrote:

What advantages/disadvantages does that have over mine? And why does Makesysop still need to be enabled?

ayg wrote:

Added in r23410.

Add Comment