Page MenuHomePhabricator

Checkuser mass blocker does not affect already blocked users
Open, MediumPublic


Author: hersfoldwiki

To duplicate:

  1. Block an account (settings on the block don't matter)
  2. Checkuser the account's IP address with "IP to users"
  3. Check the box next to the account's name
  4. Enter a block reason into the "block selected users" form at the bottom of the page
  5. Click "Block selected users"

The form will replace the content of the account's user and user talk pages as requested and expected, but the original block will not be replaced with the ACB-Autoblock-indefinite block that is expected from the form.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:09 PM
bzimport added a project: CheckUser.
bzimport set Reference to bz22890.
bzimport added a subscriber: Unknown Object (MLST).

hersfoldwiki wrote:

After some discussion on the checkuser list, it sounds as though this may be intentional; I'd still like to see this changed to overwrite existing blocks, or at least provide an option to override existing blocks (similar to bug 16306). Because of this, I've changed the severity to "enhancement". Changing the extension to handle existing blocks in this manner would mirror the current behavior of Special:Block, which will replace existing blocks with the new settings; I would assume that this is what most checkusers would expect to happen now.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 27 2015, 4:58 PM

Ran into this independently while reviewing different changes. We should at least not claim the block succeeded, and probably not edit the page.

Glaisher added a subscriber: Glaisher.EditedDec 28 2015, 6:42 AM

[...] and probably not edit the page. does this.

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptDec 28 2015, 6:42 AM
DoRD added a subscriber: DoRD.Aug 16 2017, 2:17 PM
Risker added a subscriber: Risker.Aug 16 2017, 2:31 PM
binbot added a subscriber: binbot.Aug 16 2017, 4:41 PM

"The form will replace the content of the account's user and user talk pages as requested and expected"
Does not work for me.

Meno25 removed a subscriber: Meno25.Nov 23 2018, 7:28 AM

Some history:
Mass blocking was originally added in T14808: Blocking and tagging from checkuser interface in [1] by @aaron. At the time, it overrode all non-range blocks:

// Kill old blocks, but leave range blocks
$oldblock = Block::newFromDB( $u->getName() );
if( $oldblock && $oldblock->mAddress == $u->getName() && $block->mRangeStart == $block->mRangeEnd ) {

Later, however, T17411: Repeated blocks can be inserted by CheckUser pointed out that this might not be a good thing, and in [2] (again by @aaron) this was disabled, and no blocks were overwritten.

In T92546: Migrate creation of block logs in CU mass blocker to new logging system, doMassUserBlockInternal was cleaned up, and, among other changes made, if the user was already blocked, not only are they not re-blocked, but their pages aren't edited:

$oldBlock = Block::newFromTarget( $u->getName() );
if ( $oldBlock ) {
	// If the user is already blocked, just leave it as is

This has been refactored a bit since then, but I couldn't find another change in the behaviour. Thus, currently the function reads, in relevant part

$u = User::newFromName( $name, false );
if ( $u->getBlock() ) {
	// If the user is already blocked, just leave it as is

Potential options:

  • Decline this task, since blocks should not be overwritten, and if no new block is issued, the pages shouldn't be edited
  • Change the behaviour to, even if no block is issued to avoid overwriting existing blocks, still edit the user and user talk page
  • Change the behaviour to detect if the previous block was a checkuser block:
    • If it was, the request was likely repeated, as was the case in T17411: Repeated blocks can be inserted by CheckUser - the first request should have edited the pages as well, so do nothing
    • If it wasn't, overwrite the existing block and edit the user and user talk pages

I believe that the third option is the best, since it most closely matches expected functionality. However, it does not appear that there is a way to detect from a block log if a block was a checkuser block or not. Tagging Anti-Harassment team, which is currently working on the CheckUser extension, to take a look


DoRD removed a subscriber: DoRD.Dec 5 2019, 2:08 AM