When you say levels, you do mean 30 would have the privileges of 0 and 10 as well as the privilege to protect pages? Wouldn't it be better to be able to define groups with different sets of privileges? I know someone was working on a more fine grained permission system, is that now dead in the water?
Ryan Lane
-----Original Message----- From: wikitech-l-bounces@wikimedia.org [SMTP:wikitech-l-bounces@wikimedia.org] On Behalf Of Dori Sent: Thursday, June 09, 2005 7:57 AM To: Wikimedia developers Subject: Re: [Wikitech-l] User groups changed again
On 6/9/05, Brion Vibber brion@pobox.com wrote:
I've reworked the user_groups system, again, into something that seems to actually more or less work for now.
- user_groups ur_group is now a short string key ('sysop' etc)
I think it'd probably be better to get rid of the strings and use levels instead. Level 0 (reader), level 10 (editor), level 20 (page mover), level 30 (can protect pages) level 40 (can block) etc. It's going to be a lot more work to get this to work, but as long as it's getting reworked. Optionally another table could have mappings that are easier to understand: i.e. sysop <= 50, bureaucrat <= 100, etc for backwards compatibility.
Maybe it would be too much for getting this release ready though... _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Lane, Ryan wrote:
When you say levels, you do mean 30 would have the privileges of 0 and 10 as well as the privilege to protect pages? Wouldn't it be better to be able to define groups with different sets of privileges? I know someone was working on a more fine grained permission system, is that now dead in the water?
There are three parts:
1) Assigning group memberships to users 2) Assigning permission sets to groups 3) Having useful permissions in the first place :)
In the old code, 1) was stored as a comma-separated list in user_rights. Now it's a slightly different format in user_groups, but it's basically the same. The set of groups is open-ended; you can add keys in $wgGroupPermissions and they should show up in the Special:Userrights interface.
2) was implicit through 1.3, with a few hardcoded checks in various places in the code for particular group names ('sysop', 'bureaucrat', etc). In 1.4 some bits of this were genericized, with the User::isAllowed() function; this is more genericized in 1.5. Currently the set of permissions conferred by a group membership are set in a global config variable, $wgGroupPermissions.
As for 3), for particular checks it depends on the code that's using it. Things check for named permissions like 'move', 'protect', etc.
When you get into things like 'can this user edit or view this particular page' it's a little hazier; the protect/unprotect system is a fairly blunt instrument and doesn't currently allow you to, say, indicate that a page is supposed to be editable by anyone in the 'marketing' or 'management' groups but not by anyone else.
In theory the backend *does* let you do exactly that if you set page_restrictions right -- having the restriction key in your group membership gives you permission to edit the page while people who don't have a matching key can't edit it. However I haven't tested it for non-default keys and it may be broken. If it's broken it probably should be fixed, but someone wanting 'fine-grained permissions' meaning 'marking aprticular pages as editable' would also need a UI front-end for dealing with that, which we don't have now.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org