Last modified: 2014-11-17 09:21:19 UTC
Eponymous.
(Batch change) These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.
[Batch change] Removing Dave McCabe from CC, who I somehow managed to add to the CC list of 12 bugs assigned to me.
Dupe of bug 23114 ?
(In reply to comment #3) > Dupe of bug 23114 ? Absolutelly not. Bug 23114 talks about *local* autoblocking of suppressed accounts only (lock + suppress). What it is requested here is to globally autoblock the IP(s) of an account when it is locked/lock-hidden/lock-suppressed. This would save us stewards *a lot* of time when dealing with cross-wiki disruption. Preferably it would be better if we could have a checkbox in the form to select if in that lock we want to activate global autoblock, etc.
I see. You want the ip autolocked even for projects they have never been.
(In reply to comment #5) > I see. You want the ip autolocked even for projects they have never been. Kind of it happens when you locally block an account with account creation blocked + autoblock. The system could set a global autoblock (global IP block) on the IP. Until global blocking of accounts is possible, this would be very helpful. Thank you.
This depends on creating global blocks. Which could be nice for other tasks, such as global proxy blocking. Although I have also seen meta admins going wild blocking proxys, too.
(In reply to comment #7) > This depends on creating global blocks. Which could be nice for other tasks, > such as global proxy blocking. Although I have also seen meta admins going wild > blocking proxys, too. For reference, global IP blocking already exists. I'm not sure if this includes ranges (I assume so).
Right. There's GlobalBlocking extension. I did check http://meta.wikimedia.org/wiki/Special:Log before sending comment #7, and I would say the 'Global IP block' option wasn't there... :(
(In reply to comment #8) > For reference, global IP blocking already exists. I'm not sure if this includes > ranges (I assume so). Yes. IP Rangeblocks (up to /16 ones) can be made with the GlobalBlocking extension, already avalaible to us. However global *b*locking of accounts is not possible at present. See bug 15294 for such a request or possibly bug 18182 too. (In reply to comment #7) > This depends on creating global blocks. Which could be nice for other tasks, > such as global proxy blocking. Although I have also seen meta admins going wild > blocking proxys, too. Currently we globally lock plain vandal accounts and plain abusive usernames. Notwithstanding since the user IP addresses are not affected by global locks (as opposed to a local block with autoblock + account creation blocked) the user can simply continue creating abusive accounts until it hits the account creation per IP limit. Having the option to autoblock the IP with account creation blocked globally will save us a lot of time having to manually get IPs of vandal accounts and blocking them to avoid ie: switching to another wiki or continue vandalizing, which is very annoying. Thank you.
Removing ASSIGNED status as no real person seems to be taking care of this (wikibugs is just a mailing list) --> NEW I suggest too raising the priority to normal. If this existed our work would become easier. Thanks. + crosswiki -- Two extensions involved: CentralAuth + GlobalBlocking. Regards.
I've put the priority to normal, as suggested above. We're now waiting for three years. It would be very nice if this could be processed, even if I agree that it would be time-consuming for developers. But the time you will spend doing this is insignificant regarding the time stewards have lost due to this for now. As Marco Aurelio said above, this will be an amazing gain of time. Now, when stewards want to globally block a crosswiki vandal, they have to perform the following operations : 1- lock the account 2- give themselves the CheckUser status locally 3- check the user IP 4- block the IP globally 5- remove themselves the CheckUser status 6- lock and delete the stuff the vandal has spread between the time the account has been locked and the IP globally blocked If we had an auto-block that works, we would no more have to perform the last five points. The gain of time is at least 80%. Moreover, some vandals know we can't perform checks on projets with local CheckUsers. Indeed, the steward policy forbids us to do this. So sometimes they play with us creating multiple accounts to vandalize, and move from a wiki with local CUs to an other. And we have to wait sometimes for dozens of minutes that a local CheckUser is available to perform the check and to globally block the IP. I hope I was convincing enough. Thanks for your understanding. Quentinv57
It looks easy to make an account lock (optionally) insert a globalblock row. globalblocks table would need a gb_auto column and filtering to not show the ip address in that case. It's a different approach than the one used in 'normal' autoblocks, but looks more appropiate. A problem would be that unlocking would need manual unblocking of the ips, though. But seems acceptable.
