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

Similar to T370417, this should be optional.

With T359116 on the horizon, I would argue that we should implement the autoblocks for GlobalBlocking account blocks and not implement this task by converting all locks into GlobalBlocking blocks.

Expanding on my thoughts from my last comment, I think we should decline this in favour of T368949 and fold global locking into the global blocking system.

Having started work on implementing GlobalBlocking autoblocks in T368949, I've found that the work needed will be large and involve a fair bit of work to link CheckUser and GlobalBlocking together. Implementing this for MediaWiki-extensions-CentralAuth locks is possible, but will also involve a large amount of work. For example:

1. This will add code, functionality, and UI to MediaWiki-extensions-CentralAuth that is only used when CheckUser and GlobalBlocking are both installed. As CheckUser is not installed on the beta clusters, this adds code which cannot be tested on the beta clusters.
2. This will also involve adding extra code to GlobalBlocking to understand, deal with, and undo autoblocks that are not associated with a global block, which will at least involve a Schema-change to GlobalBlocking that will be unused unless MediaWiki-extensions-CentralAuth is installed (and therefore is likely a WMF-only specific change)

I would argue is not worth the extra time to implement this task if we are planning to merge locking into the GlobalBlocking extension. This is especially because we would need to undo nearly all of the changes made to support autoblocks for locks so that we can merge the two systems together.

As CheckUser is not installed on the beta clusters

I agree with the wider point but isn't this a self-inflicted problem? It shouldn't be hard to install it on Beta and prevent it from logging real user data, e.g. by adding a hook where the data about to be logged by CheckUser can be preprocessed.

In T19929#10074877, @Tgr wrote:

As CheckUser is not installed on the beta clusters

I agree with the wider point but isn't this a self-inflicted problem? It shouldn't be hard to install it on Beta and prevent it from logging real user data, e.g. by adding a hook where the data about to be logged by CheckUser can be preprocessed.

Sure. We may want to add it to the beta clusters for global blocking auto blocks from global blocks, but we should be able to test that easier locally because you don't necessarily need MediaWiki-extensions-CentralAuth.

In T19929#10075136, @Dreamy_Jazz wrote:

In T19929#10074877, @Tgr wrote:

As CheckUser is not installed on the beta clusters

I agree with the wider point but isn't this a self-inflicted problem? It shouldn't be hard to install it on Beta and prevent it from logging real user data, e.g. by adding a hook where the data about to be logged by CheckUser can be preprocessed.

Sure. We may want to add it to the beta clusters for global blocking auto blocks from global blocks, but we should be able to test that easier locally because you don't necessarily need MediaWiki-extensions-CentralAuth.

See: T357959: Install CheckUser in Beta Cluster

In T19929#10073300, @Dreamy_Jazz wrote:

• This will also involve adding extra code to GlobalBlocking to understand, deal with, and undo autoblocks that are not associated with a global block, which will at least involve a Schema-change to GlobalBlocking that will be unused unless MediaWiki-extensions-CentralAuth is installed (and therefore is likely a WMF-only specific change)

I would argue is not worth the extra time to implement this task if we are planning to merge locking into the GlobalBlocking extension. This is especially because we would need to undo nearly all of the changes made to support autoblocks for locks so that we can merge the two systems together.

I agree with these points and suggest we decline this task, unless there are objections.