Split off bug 14801: The ability to set permissions per namespace.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | Feature | None | T31781 Add support for per-namespace permissions for global user groups | ||
| Open | Feature | None | T31780 Implement a way to set user group permissions per namespace |
I'm proposing this for 1.20
It's been attempted last year by Bryan but it wasn't good enough for some reason, I think it is not too much asked to make this a milestone 1.20
The community has requested and voted about this in *2008* (see bug 14801), and it's probably the lowest hanging fruit we have to make commons' admins life a whole lot easier (it's a relatively easy thing to do and will have a huge impact on Commons (right now image reviewers have to manually contact local admins for every file separately and that's no way to work (especially since it takes for ages to get in touch with one and then the usual controversy of them having to publicly undelete it for a commons admin to look at and then re-delete it), as a result the files are added to a giant pile for later)..
(In reply to Bryan.TongMinh in bug 14801 comment #40)
I would prefer this to have this dependant of a Title->userCan(), and having a
way to set per namespace $wgGroupPermissions in a sane way.We are talking about global groups, so $wgGroupPermissions seems irrelevant.
Your suggestion though would imply implementing per-namespace group permission
support in CentralAuth.On an unrelated note a sane way for $wgGroupPermissions to support
per-namespace permissions is to allow an array as argument, e.g.$wgGroupPermissions['sysop']['deletedhistory'] = array( NS_FILE => true );
In any case I think setting permissions per-namespace is the way to go, rather
than creating per-namespace permissions.I agree. So the userright-key in the user-group array in $wgGroupPermissions is
either boolean or an array of namespace-ids with booleans.
Although I agree making the rights namespace-settable is better than introducing new rights, doing it the way you describes above does bring a problem with compatibility.
It becomes very hard for extensions to set them because local wikis may have other settings that don't count on this, and vica-versa. Doing this from a hook instead (where it would allow the permission until if an extension returns false because on the permission-key and a $Title object) may be more scalable and easier compatibility wise.
Maybe something to consider :)