Last modified: 2008-05-08 23:51:44 UTC
Ipblock-exempt, for those who don't know, makes trusted users immune from hardblocks on IPs and other autoblocks. http://bugzilla.wikimedia.org/show_bug.cgi?id=3706 https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Wikipedia_Signpost/2007-01-08/Technology_report Apparently, by default this feature is only given to administrators. A Bugzilla request is required to make it available separately, so it can be given to trusted users who are not administrators. http://www.gossamer-threads.com/lists/wiki/wikitech/80058?do=post_view_threaded Therefore, I a requesting that a separate group be created on en.wikipedia, so that trusted users can be given ipblock-exempt without being given adminship. It might also be a good idea to let admins give out ipblock-exempt, so they can handle requests for it as part of their regular routine in handling unblock requests.
This basically has the same dependency on some interface to assign membership of the subsequent group to users as other similar proposals.
(In reply to comment #1 by Rob Church) > This basically has the same dependency on some interface to assign membership of > the subsequent group to users as other similar proposals. So allowing stewards to assign users to such a group would be easier to implement than allowing regular administrators to assign users to such a group?
(In reply to comment #2) > So allowing stewards to assign users to such a group would be easier to > implement than allowing regular administrators to assign users to such a group? That's correct, at least for the moment. Individual permissions such as sysop and bot permissions are currently fulfilled by extensions (e.g. Makesysop, MakeBot) on Wikimedia wikis, where bureaucrats cannot be given standard user rights permissions.
(In reply to comment #1) > This basically has the same dependency on some interface to assign membership of > the subsequent group to users as other similar proposals. If the user group were to be created, would it work immediately with the steward interface, or would changes need to be made to that first? Sorry if I've misread :)
(In reply to comment #4) > If the user group were to be created, would it work immediately with the steward > interface, or would changes need to be made to that first? It would work immediately with the steward interface.
Would it be possible to add it then, if only as a stop-gap measure to help those immediately affected by the hardblocking of anonymous open proxies, and to a wider extent, to help those affected by school blocks?
Note: This was tested on MedComWiki, courtesy of Martinp23. Works with bureaucrat interface. Can be applied to DefaultSettings.php or LocalSettings.php. Index: includes/DefaultSettings.php =================================================================== --- includes/DefaultSettings.php (revision 22495) +++ includes/DefaultSettings.php (working copy) @@ -987,6 +987,9 @@ $wgGroupPermissions['bot' ]['nominornewtalk'] = true; $wgGroupPermissions['bot' ]['autopatrol'] = true; +// Users in ipblock-exempt group are immune from ip hardblocks and other autoblocks, but may still be blocked directly. +$wgGroupPermissions['ipblockexempt']['ipblock-exempt'] = true; + // Most extra permission abilities go to this group $wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop']['createaccount'] = true; Index: RELEASE-NOTES =================================================================== --- RELEASE-NOTES (revision 22495) +++ RELEASE-NOTES (working copy) @@ -40,6 +40,8 @@ images to a fix value which makes views for anon unproportional and user preferences useless * (bug 6072) Add a 'border' keyword to the image syntax +* (bug 9862) New group for ipblock-exempt, so users can be immune from +ip hardblocks and other autoblocks without being sysops. == Bugfixes since 1.10 ==
Works with Special:Userrights - Makesysop isn't installed, nor Makebot, so it wouldn't work with the standard 'crat interface - only the stewards.
Oh, I thought Special:Userrights was the bureaucrat interface.
This is not a request to have this added by default in the software. It's a request to enable it on a specific wiki. Doing so is not necessarily useful until bug 6711 is fixed (due to steward intervention required), or at least sysadmins don't seem interested in fulfilling these kinds of requests until it is.
I'm working on writing an extension called Special:MakeIPExempt. Provided you set the info in LocalSettings.php as outlined above, a BCrat (or sysop, if they're given access to it) could give an individual user ipblock-exempt.
Created attachment 3734 [details] Main extension file This and the following two files create the Special:Makeipexempt extension. It allows B-crats to grant the Ip-block group to users. Stewards default to the main user rights screen. Basically a port of MakeSysop, only without the ability to set the b-crat flag. This requires the following line to be set within LocalSettings.php, as mentioned above. $wgGroupPermissions['ipblock-exempt']['ipblock-exempt'] = true;
Created attachment 3735 [details] Second file for extension
Created attachment 3736 [details] Localization file
1) You can (and ideally should) combine all patch files into a single patch using the command "svn diff". 2) It's ludicrous to add yet another MakeX extension. Let's fix bug 6711 instead.
Note: with bug 6711 fixed, this can be done, if a sysadmin can be found to do it.
Can we get a sysadmin to add the group? Perhaps then we could shell out a policy on how to give this permission to non-admins. ~~~
Any progress on this bug thus far?
(In reply to comment #18) > Any progress on this bug thus far? > Given the recent fallout with rollback, this most certainly will need consensus before implementation on a wiki. (Circumstances have also changed, so patch may no longer be valid.)
(In reply to comment #19) > Given the recent fallout with rollback, this most certainly will need consensus > before implementation on a wiki. (Circumstances have also changed, so patch > may no longer be valid.) > Yes - there will probably need to be a clear consensus on WP:VPT or similar first, and some mechanism to decide how to hand it out. There wouldn't be any issues with the patch not being valid, because the fix for the bug at the moment wouldn't involve applying a patch - it's a matter of changing the mediawiki config to allow 'crats (probably) to assign ipblock-exempt just as was done with admins and "rollbacker". I suspect the bug should be reopened when consensus is reached?
(In reply to comment #20) > I suspect the bug should be reopened when consensus is reached? > Yup.
I would ask that the developer not just take one person's word on consensus about it. It's not really fair to put developers in the position of judging consensus in the first place.
Oh no, I don't think there is any local policy or consensus yet. I wanted to propose one, but I wanted to know if this bug were technically possible before I propose.
Here you go. http://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption Merc
That consensus isn't real yet I don't think, I just rolled it back. So, devs, please hold off a bit before implementing this...
Need more time per Lar.
Without commenting on the presence or absence of consensus for this, the recent improvements in the flexibility of control over the assignment of user flags in MediaWiki are going to make this a hell of a lot easier to implement. For example: =================================================================== File: /LocalSettings.php $wgAddGroups['sysop'] = array('rollbacks', 'ipblock-exempt'); $wgRemoveGroups['sysop'] = array('rollbacks', 'ipblock-exempt'); $wgGroupPermissions['ipblock-exempt']['ipblock-exempt'] = true; =================================================================== Note, I am unsure if the rollback group is defined as "rollbacks" or "rollback"; it is the former in enwiki's Special:Listusers, but that may be an aesthetic change through MediaWiki:Group-rollbacks, or what not. Additionally, ArmedBlowfish's post a few months ago noted that the change could be made in DefaultSettings.php; I'm sure that's a huge no-no on MediaWiki, but I may be wrong there. I'm sure the developers can point the correct route with regards to that.
(In reply to comment #27) > Without commenting on the presence or absence of consensus for this, the recent > improvements in the flexibility of control over the assignment of user flags in > MediaWiki are going to make this a hell of a lot easier to implement. Yes, this is certainly possible now. The issue is only consensus. > Additionally, ArmedBlowfish's post a few months ago noted that the change could > be made in DefaultSettings.php; I'm sure that's a huge no-no on MediaWiki, but > I may be wrong there. I'm sure the developers can point the correct route with > regards to that. Keep in mind that by default there are only three assignable groups: sysop, bureaucrat, bot. And bot probably shouldn't be on that list. The default list of groups is deliberately minimal, on the assumption that most wikis can basically have a two-tiered system of users and sysops (plus, say, one active bureaucrat). The Wikipedias are unusual in terms of things like this, partly because of size, and partly (IMO mainly) because the ones who can give sysop status generally can't revoke it, unlike in the default configuration. So, no, I can say we are definitely not going to add an ipblock-exempt group by default. Please keep any further discussion on this issue in a new bug filed under the MediaWiki product, which you can probably mark as depending on this one (since fixing it would fix this).
The relevant page on enwiki has been marked as a policy after discussion on the talk page died down. http://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption The final version of the policy would allow administrators to grant the right. $wgGroupPermissions['ipblock-exempted']['ipblock-exempt'] = true; $wgAddGroups['sysop'] = array( 'rollbacker', 'ipblock-exempted' ); $wgRemoveGroups['sysop'] = array( 'rollbacker', 'ipblock-exempted' );
Sorry if I'm butting in inappropriately, but is there any progress on implementing this? It seems to be a policy with strong consensus behind it.
Shell users will handle shell requests as they have the time and inclination. Most are volunteers, just as are all the Wikipedians who want the feature. Please be patient. You can hassle people at irc://irc.freenode.org/wikimedia-tech if you want.
Is there any reasonably easy way to make it possible to remove ipblock-exempt from admins (specifically, I want the ability to remove the flag from myself, because I don't need it and therefore it's just a security risk should my account become compromised)? One method that would presumably work would be to remove ipblock-exempt from admins by default and assign the separate group to all admins as it was created, but I don't know whether doing that is easy or difficult.
It can be easily set up by the shell users. If you get consensus, open a new bug (keyword "shell") to remove ipblock-exempt from sysops.
There is /no/ consensus anywhere for such a change, fwiw. This is a single user asking to have it removed, and if not, remove it from all sysops and then put them in the group to allow it specifically.
(In reply to comment #34) > There is /no/ consensus anywhere for such a change, fwiw. This is a single user > asking to have it removed, and if not, remove it from all sysops and then put > them in the group to allow it specifically. > Yes, to clarify, I'm not asking to de-ipblock-exempt all sysops, just wondering how easy it would be to remove that just for myself. I doubt that such a change would require consensus (just like self-desysopping doesn't), but it's possible that it's not very easy for shell users to do.
Please don't use Bugzilla for general questions or discussion about the MediaWiki software or Wikimedia configuration. Try irc://irc.freenode.org/mediawiki, the Wikitech-l mailing list, direct e-mail to someone you think knows the answer, or similar means. Thank you.
Added. Please confirm it's working correctly. :)
Confirmed, thanks :D
