(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.

quentinv57 wrote:

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.

Maybe we should ask an performance expert, because suppressing auser requires actually a job, which blocks him at all wikis. I'm not a steward, so I can't controll this, but I guess you lock more accounts then hide or suppress accounts, so this can be a performance problem.

And: Before we create this, we have to fix T28476. Otherwise a steward who locks a account in error, and wants to revert it, have to unblock the user in every wiki. Sounds like much fun, if you have to unblock the user at (for example for my account) 394 wikis. :-/

Yeah, the current system is actually quite inefficient and has several issues because it requires sending blocks to all the wikis and these can be hard to manage. Proper way to go forward would be to implement a central blocking system in GlobalBlocking extension as suggested above.

In T19929#2239938, @Glaisher wrote:

Proper way to go forward would be to implement a central blocking system in GlobalBlocking extension as suggested above.

Ok, if so T17294 is a blocker, right? Note that this feature request is also about making the local wiki aware of the IP addresses used by the blocker user on another wiki. Or did you mean that you want to "centralise" the implementation of the IP blocks alone?

In T19929#228729, @bzimport wrote:

quentinv57 wrote:
I've put the priority to normal, as suggested above. We're now waiting for three years.

The Priority field should reflect reality but does not cause it... So I'm afraid this is de facto low priority (as it was initially).

It would be very nice if this could be processed, even if I agree that it would be time-consuming for developers.

Wondering if someone could bring up this task for the next Community Wishlist round, to give it more attention?

This is very important for stewards.

Today I locked cross-wiki vandal, and then I went to login.wikimedia.org to checkuser the account, and at this time he had created another account and was already vandalizing before I globally blocked the IP.

In T19929#228729, @bzimport wrote:

quentinv57 wrote:

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

Well articulated rationale. I don't think I could've articulated a better, more concise use case.

Thanks for this.