Last modified: 2014-10-17 22:07:01 UTC
Currently, anyone with the "block" right is able to block any user. Because of this, situations sometimes arise in which sysops get in wheel wars pointlessly blocking and unblocking each other until a bureaucrat intervenes. It would be better to make it possible to prevent sysops from blocking or unblocking other sysops. So, I propose creating $wgBlockGroups and $wgUnblockGroups config settings that are analogous to $wgAddGroups and $wgRemoveGroups. E.g.: $wgBlockGroups['bureaucrat'] = true; $wgBlockGroups['sysop'] = array( 'autoconfirmed', 'bot' ); This would prevent a sysop from blocking a user who is in a group other than 'autoconfirmed' or 'bot'.
Actually we don't need the $wgUnblockGroups config setting.
Change 167157 had a related patch set uploaded by leucosticte: Add $wgBlockGroups config setting The $wgBlockGroups config setting makes it possible to restrict users to only blocking users who are not in certain groups. For example: https://gerrit.wikimedia.org/r/167157
I have some doubt that "wheel wars where admins keep blocking and unblocking each other" really occurs often enough to be worth the added complexity of having this configuration option and having to decide what goes in it for each group. Let them play around until 'crats can desysop them both. Keep in mind that in practice these lists are going to be more along the lines of "array( 'bot', 'reviewer', 'autoreview', 'accountcreator', 'import', 'transwiki', 'ipblock-exempt', 'oversight', 'founder', 'rollbacker', 'autoreviewer', 'researcher', 'filemover', 'checkuser', 'templateeditor', 'massmessage-sender', 'OTRS-member', 'abusefilter', 'epcoordinator', 'eponline', 'epcampus', 'epinstructor', 'oauthadmin', 'confirmed' )" than "array( 'bot' )" and would have to be updated every time a new group gets added.
If a wiki really wants this, it should be done in an extension. For one thing, it's not unheard of for a sysop to legitimately block another sysop, but this would unconditionally prevent that, if the configuration mentioned in the description were implemented. Also, we currently don't have anything even remotely related to hierarchies like this in the core, and I don't think it would be good to start.
(In reply to Brad Jorsch from comment #3) > Keep in mind that in practice these lists are going to be more along the > lines of "array( 'bot', 'reviewer', 'autoreview', 'accountcreator', > 'import', 'transwiki', 'ipblock-exempt', 'oversight', 'founder', > 'rollbacker', 'autoreviewer', 'researcher', 'filemover', 'checkuser', > 'templateeditor', 'massmessage-sender', 'OTRS-member', 'abusefilter', > 'epcoordinator', 'eponline', 'epcampus', 'epinstructor', 'oauthadmin', > 'confirmed' )" than "array( 'bot' )" and would have to be updated every time > a new group gets added. One could do, a la SpecialListgrouprights.php, $allGroups = array_unique( array_merge( array_keys( $groupPermissions ), array_keys( $revokePermissions ), array_keys( $addGroups ), array_keys( $removeGroups ), array_keys( $groupsAddToSelf ), array_keys( $groupsRemoveFromSelf ) ) ); And then array_diff the ones one doesn't want.
(In reply to Nathan Larson from comment #5) > One could do, a la SpecialListgrouprights.php, > > $allGroups = array_unique( array_merge( > array_keys( $groupPermissions ), > array_keys( $revokePermissions ), > array_keys( $addGroups ), > array_keys( $removeGroups ), > array_keys( $groupsAddToSelf ), > array_keys( $groupsRemoveFromSelf ) > ) ); > > And then array_diff the ones one doesn't want. Oh wait, maybe one couldn't do that.
