Rob Church wrote: 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 -- Phil PS Good to hear from you, even if you are rightfully chastising me for my woeful ignorance ;-) -- View this message in context: http://www.nabble.com/Special%3ADesysop-tf2108462.html#a5812151 Sent from the Wikipedia Developers forum at Nabble.com.

On 15/08/06, Filip Maljkovic &lt;dungodung(a)gmail.com&gt; wrote: 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 &lt;dungodung(a)gmail.com&gt; wrote: 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 &lt;Simetrical+wikitech(a)gmail.com&gt; wrote: 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 &lt;Simetrical+wikitech(a)gmail.com&gt; 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". 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 &lt;Simetrical+wikitech(a)gmail.com&gt; 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. 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 &lt;robchur(a)gmail.com&gt; wrote: 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: It's possible ? although it drops the group blacklist feature, I'm not sure someone will ever use the blacklist. Of course. 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 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. - -- #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: 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