Rob Church wrote:

On 15/08/06, Phil Boswell phil.boswell@gmail.com wrote:

...

Andrew Garrett wrote:

...

Questions, comments and requests for demonstrations are more than

welcome. This is obviously going to be a great help to other users of Mediawiki as well. It makes good sense to have a proper UI for as many of these delicate operations as we can manage.

Phil, MediaWiki contains a built-in rights management interface. It makes more sense to me if we fixed up one extension for Wikimedia which combined Makesysop, Makebot, Giverollback and now this...thing...into something manageable and useful. Configuration can determine what groups can grant and revoke which rights. Four different pages to do similar tasks is pushing the boundaries.

Can't argue with that...in my defence, m'lud, I have no access to anything like that AFAIK so had no way of knowing about it.

Another way of looking at it is that this would give local administrators the choice of having a monolithic interface which does everything, or simply enabling the individual operations as they wanted.

Obviously it would make sense to coordinate the monolithic and separate interfaces to ensure they use common code where appropriate.

So now we need some way of configuring the configuration tools...<lapses into incoherent babble>

Well, at least now we have something to work with...quite the wiki-way ;-)

Cheers...HAND

On 15/08/06, Filip Maljkovic dungodung@gmail.com wrote:

Since the talks have continued in wikitech-l, I'll reply there.

I think this is a great idea and would be of great help to big local communities as well as some kind of relief for stewards. I absolutely agree that local Bureaucrats can be trusted enough to use this function wisely. On the other hand, as for the technical aspect, I concur with Rob Church - all the special pages dealing with userrights should be merged and robchurch seems to be the perfect guy for that ;)

Me and my big fucking mouth.

It'll have to wait, then. Although, wasn't Rotem Liss doing something in a branch?

Rob Church

On 8/15/06, Filip Maljkovic dungodung@gmail.com wrote:

But this whole thing got me thinking: what we basically want is what already exists: Special:Userrights, where bureaucrats can give/revoke every userright possible.

Now if you/anyone finetune(s) that special page, and Brion gives consent, voila!

Exactly my thought of a month ago: http://bugs.wikimedia.org/show_bug.cgi?id=6711

Well, this is similar to what I was trying to do, and got stuck doing, mostly because I'm still quite a PHP novice.

I was thinking of modifying Special:Userrights to allow users with varying degrees of permission to make user group changes. For example, you could allow sysops to assign a few permissions (e.g. rollback, autoconfirmed, or even a "validate" group for stable versioning), but not allowed to revoke them; then, bureaucrats would be able to grant additional privileges, but not be able to revoke a few, if needs warrant. Finally, stewards would be able to change everything.

The way I had been going at it is to declare those in an array in LocalSettings.php. For example, I had:

$wgGroupPermissions['*' ]['validate'] = false; $wgGroupPermissions['*' ]['changeuserprivs'] = false; $wgGroupPermissions['validator' ]['autoconfirmed'] = true; $wgGroupPermissions['validator' ]['validate'] = true; $wgGroupPermissions['sysop' ]['changeuserprivs'] = true; $wgGroupPermissions['bureaucrat' ]['changeuserprivs'] = true;

This would define a "validator" group for stable versioning, and a "changeuserprivs" permission to reach the hacked version of Userrights. Then, I declared an array, which says who can change what:

$wgUserPrivsArray['validate' ] = array('sysop,bureaucrat,steward', 'sysop,bureaucrat,steward'); $wgUserPrivsArray['rollback' ] = array('sysop,bureaucrat,steward', 'bureaucrat,steward'); $wgUserPrivsArray['bot' ] = array('bureaucrat,steward', 'bureaucrat,steward'); $wgUserPrivsArray['sysop' ] = array('bureaucrat,steward', 'steward'); $wgUserPrivsArray['bureaucrat'] = array('bureaucrat,steward', 'steward'); $wgUserPrivsArray['steward' ] = array('steward', 'steward');

The key name is the name of the permission to grant; the first entry in the key array is who is allowed to grant the permission, and the second is who is allowed to revoke it. For example, bureaucrats could be created by other bureaucrats and stewards, but only stewards could revoke bureaucrat rights. Now, this allows for customizing and extending user privileges in a single place.

Titoxd.

-----Original Message----- From: Simetrical [mailto:Simetrical+wikitech@gmail.com] Sent: Tuesday, August 15, 2006 8:15 AM To: Wikimedia developers Subject: Re: [Wikitech-l] [Wikipedia-l] Special:Desysop

On 8/15/06, Simetrical Simetrical+wikitech@gmail.com wrote:

Exactly my thought of a month ago: http://bugs.wikimedia.org/show_bug.cgi?id=6711

Ack, seems this comment is a few hours out-of-date. Multiple threads! Confusing! . . . er, anyway, good job Rotem, now wikis that want them can assign rollback and stuff if Brion's okay with this change. See the two bugs depending on the above.

On 15/08/06, Simetrical Simetrical+wikitech@gmail.com wrote:

I still prefer my syntax for deciding assignment rights, namely

$wgUserPermissions['bureaucrat']['addgroup']['sysop'] = true; $wgUserPermissions['bureaucrat']['addgroup']['bureaucrat'] = true; $wgUserPermissions['bureaucrat']['addgroup']['bot'] = true; $wgUserPermissions['bureaucrat']['remgroup']['bot'] = true;

I don't, it's too easily confused with $wgGroupPermissions and the two aren't compatible. However, rename the variable to something appropriate, e.g. $wgRightsManipulation (ick, someone think of a better phrase) and the format makes some sort of sense, although of course, we could then switch the middle portion to be "add" or "remove".

One thought that's fairly negligible at this stage, and kinda obvious, but if $wgRightsManipulation, or whatever, was not set, or set to false or null (and that'd be the default), then any user with the "userrights" permission could use the form, as it is now.

I still feel this kind of complicated control is better off as an extension, let's face it; who's going to want to use it besides Wikimedia and a couple of other large installs? Best to keep the core implementation simple, I think. If people want it, it can be added.

I'm not convinced of the need for a "remote" permission. If access is available and $wgAlternateMaster or whatever is set, then fine, it happens, otherwise it doesn't.

Rob Church

On 15/08/06, Simetrical Simetrical+wikitech@gmail.com wrote:

On 8/15/06, Rob Church robchur@gmail.com wrote:

...

On 15/08/06, Simetrical Simetrical+wikitech@gmail.com wrote:

...

I still prefer my syntax for deciding assignment rights, namely

$wgUserPermissions['bureaucrat']['addgroup']['sysop'] = true; $wgUserPermissions['bureaucrat']['addgroup']['bureaucrat'] = true; $wgUserPermissions['bureaucrat']['addgroup']['bot'] = true; $wgUserPermissions['bureaucrat']['remgroup']['bot'] = true;

I don't, it's too easily confused with $wgGroupPermissions and the two aren't compatible.

D'oh. I *meant* $wgGroupPermissions. That is, 'addgroup' and 'remgroup' would be group permissions.

That will confuse the existing code handling it. I maintain it would be better to split up the variables; the purpose is too broadened otherwise.

Rob Church

Or using wgUserPrivsArray (or some other name) instead? Instead of defining user groups granting by attaching a permission to the granter, why not grant it to the privilege? I mean, instead of saying "sysops can give rollback" say "rollback can be given by sysops, bureaucrats and stewards"?

Titoxd.

-----Original Message----- From: Simetrical [mailto:Simetrical+wikitech@gmail.com] Sent: Tuesday, August 15, 2006 12:57 PM To: Wikimedia developers Subject: Re: [Wikitech-l] [Wikipedia-l] Special:Desysop

On 8/15/06, Rob Church robchur@gmail.com wrote:

That will confuse the existing code handling it. I maintain it would be better to split up the variables; the purpose is too broadened otherwise.

Not really. There's certainly no mileage in having a standard permission to the effect of "can change groups", and then some other variable saying what groups each specific group-changing group can change; the former is implicit if you're included in the latter.

It makes more sense to keep all group permissions in $wgGroupPermissions. That's what it's there for.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Rob Church wrote:

I don't, it's too easily confused with $wgGroupPermissions and the two aren't compatible. However, rename the variable to something appropriate, e.g. $wgRightsManipulation (ick, someone think of a better phrase) and the format makes some sort of sense, although of course, we could then switch the middle portion to be "add" or "remove".

It's possible ? although it drops the group blacklist feature, I'm not sure someone will ever use the blacklist.

One thought that's fairly negligible at this stage, and kinda obvious, but if $wgRightsManipulation, or whatever, was not set, or set to false or null (and that'd be the default), then any user with the "userrights" permission could use the form, as it is now.

Of course.

I still feel this kind of complicated control is better off as an extension, let's face it; who's going to want to use it besides Wikimedia and a couple of other large installs? Best to keep the core implementation simple, I think. If people want it, it can be added.

An extension will either duplicate logic into another special page ? like now (then every change will have to be done both in the base code and in the extension), or use hooks written especially for it ? then it will be much easier to do that in the page itself, and the extension will be very short. After all, most of the changes in the branch are not the permissions system, but the remote users, and the permissions system itself is only set in one short function ? removing it won't really simplify the code very much, especially if we add hooks behind it.

I'm not convinced of the need for a "remote" permission. If access is available and $wgAlternateMaster or whatever is set, then fine, it happens, otherwise it doesn't.

I think $wgLocalDatabases ($wgAlternateMaster is only to reach enwiki) is set in all Wikimedia sites, but only the stewards should touch the remote users, and the local bureaucrats should only add sysops, bureaucrats and bots, and remove bots *in their site*. Even if $wgLocalDatabases is set only in Meta, the local bureaucrats of Meta who are not stewards should not touch the remote users. Therefore, 'userrights_remote' should be set to false for local bureaucrats.

Rob Church

- -- #define Name RotemLiss #define Mail mail-AT-rotemliss-DOT-com #define Site www.rotemliss.com

#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0

Simetrical wrote:

A problem with Rotem's implementation is that it allows at most two levels of privilege assignment: one that abides by the permissions whitelists, and one that doesn't. If you want another level, that's impossible.

I still prefer my syntax for deciding assignment rights, namely

$wgUserPermissions['bureaucrat']['addgroup']['sysop'] = true; $wgUserPermissions['bureaucrat']['addgroup']['bureaucrat'] = true; $wgUserPermissions['bureaucrat']['addgroup']['bot'] = true; $wgUserPermissions['bureaucrat']['remgroup']['bot'] = true;

or something to that effect. It's completely flexible, and significantly simpler (if I do say so myself) than Titoxd's. If for one or more groups of the current user 'addgroup' or 'remgroup' is non-false, then Special:Userrights would become available; to determine what groups are available on each side, you'd merge the arrays from all the user's groups (conflict for a key would default to true) on each side and then foreach. The 'userrights' permission would remain, and would have the same function as now. Rotem's 'userrights_remote' would also be present, but his other three would be redundant.

Thoughts?

How about completely rewriting the permissions system? I mean, while you're doing all of this, you might as well do something a bit harder, but better (in wider perspective). The current system can lead to confusion and it has some setbacks (e.g. rights are additive) and the new system would be totally flexible and prone to all variations. If I knew PHP, I'd write it ;)

Filip