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.

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

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

In T24890#1902810, @Krenair wrote:

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

https://gerrit.wikimedia.org/r/261175 does this.

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

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 ) {
	$oldblock->delete();
}

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
	continue;
}

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
	continue;
}

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

[1] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CheckUser/+/3e508f3560adb0634e2a60ceae191782afa558fe%5E%21/
[2] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CheckUser/+/653d387ab4cbf5dc4b9de1b455b4c0fbe20330d6%5E%21

I wonder if another option is to compare the new and existing block and replace if the new block is longer/larger than the existing block.