Sechan, Gabe wrote:

I'm using MediaWiki to create a corporate wiki, and need to allow access to certain pages only to certain groups. I don't see full support for this in MediaWiki as of 1.4.11 (although there is stub support- you can do this for moderators). Unless this has already been implemented for 1.5 or there is already a 3rd party patch, I'm going to implement this myself, and will be pushing for (and almost will certainly get) permission to give this change back to the community. While Wikipedia may not use it, it would be a nice feature for the wiki in general. And if it brings in more corporate users, those users may always contribute back more useful changes.

Use 1.5 for dev. 1.4 is no longer recieving real updates. I'll be refering to the 1.5 schema in this e-mail.

By the sound of it, you are needing only per-page-per-group restrictions. (As opposed to per namespace and/or per user.)

I also noticed there is not a list of permissions in this e-mail. (Sometimes called actions in the code.) Do you have one?

This brings me to how to implement this. I have a few ideas, if anyone can comment on them.

Part 1- storing restrictions

I can either use the cur_restricted field of the cur table, or create a new table that has a pair (pagename,group). If the pagename has restrictions, you would need to be in one of those groups. If there were no restrictions, it would default to open. Which of these ways sounds preferable? I sort of like the new table, since then lookups on old versions wouldn't need to access the cur table for restrictions data.

Page/group/action (Actions requiring a certain group, stored per page) are stored in the page_restrictions in the page table. It is parsed by Title::loadRestrictions() and can be accessed by Title::getRestrictions(). (It appears to operate on a strict system, which you must be in the group to perform the action.)

Negative assertions (ie, saying a group may /not/ perform an action) appears to be unsupported.

Part 2- storing groups

A new table with pairs (user id, groupname). A user can be in any number of groups.

Already done: user_groups.

Part 3- applying restrictions

Any time someone tries to access cur_text, they need to check against permissions. If they fail, they should not actually read the text. Do only Article and EditPage need this protection, or will it need to go elsewhere as well?

Per-page viewing is difficult due to templates and transclussion. You basically have two opptions with that: - Add some restriction checks to the parser - Disallow inclussion from namespaces other than Template

I'm thinking of implementing this as a new class (Permission) with a two methods- checkPermission($user,$title) that will return TRUE if user can access the title, and FALSE if not On a FALSE, the calling code will need to push an error up the call stack in whatever way is appropriate. Probably a web page saying that the page is protected, and listing the groups.

Check current methods of the User, Article, and Title objects. (User::isAllowed(), User::isAnon(), User::isBlocked(), User::isBlockedFrom(), User::getGroupPermissions(), User::getGroups(), User::getEffectiveGroups(), Article::protect(), Article::insertOn(), Title::userCan(), Title::getRestrictions(), plus many others.)

If you want to implement per-namespace permissions, start hacking the Namespace object.

The other function is groupList($title) that will return the list of groups with permission to read it. Its there to allow callers to get allowed groups for the error page. (Alternatively, Permission could generate an error page, but that sounds messy).

See the partial list of methods above. I think it's User::getGroups() or User::getEffectiveGroups() is what you want. (Note that you should instead pass a method a permission/action and a determinator (Title for User, User for Title).)

Part 4- editing permissions

An extra box on the edit page, with a list of groups. Add a group to add it to the restricted to list. You must have edit permissions (in other words, you must be in one of the previously allowed groups or be an admin/beauracrat) to add or remove a group.

Shouldn't this be a seperate page? Also, what about a global 'editperms' permission?

Part 5- adding people to groups

Basicly, this is a special page. I'll probably allow, as a basic method, any admin, beauracrat, or existing group member to add you to a group. I'm not as interested in this part of the problem, as I'll be getting my groups from /etc/group.

Special page is probably the way to go. Just make sure you have a permission for it (so a user can't add themselves to the sysop group).

Any comments on how I plan to implement this? Or if it already exists and I'm being a moron (or missing a 3rd party patch somewhere), please help me out.

One thing that's missing in the current system implemented in MW is that there's no way to link a group with a global permission (w/o editting LocalSettings.php).

-- Jamie ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.