https://bugzilla.wikimedia.org/show_bug.cgi?id=29780
Krinkle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected], | |[email protected], | |[email protected], | |[email protected] --- Comment #2 from Krinkle <[email protected]> 2012-04-12 15:12:46 UTC --- (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 :) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
