On enwiki, it's common for CUs to ask (typically on IRC), "Can somebody block this IP for me?" in order to obfuscate the connection between accounts and IPs blocked from the same case. Or, you just make yourself a note to execute the IP block later in the day. Either way, somebody perusing the public block logs won't see an obvious connection between the account(s) and the IP(s).

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

When you block an IP in CU, you get an option to either block it immediately, or to queue it for somebody else to block. If you select the later, it goes onto a queue which is only visible to other CUs. Then it could be part of the job of other CUs to watch that queue and perform the blocks. Or, maybe when you put the IP on the queue, you've got an option to select either "Automatically execute this block in my name after N hours" or "Queue this for quick attention by another CU". For most IP blocks, a delay of a few hours isn't going to be a problem, so I would expect setting up a delay would be the most common option.

As a related item, when CUs block IPs, they intentionally don't identify the related SPI case in the block comment. The problem with this is that another CU looking at the block log in the future will have no idea what the block was for. To solve that, I've taken to commenting CU IP blocks with an obfuscated link to the cuwiki page, i.e. https://en.wikipedia.org/w/index.php?title=Special:Log&logid=134015222. The queue idea could incorporate that. When the IP block is finally executed (either by another CU or after a delay), it could automatically include a link to the CU-only-visible queue entry, which in turn would indicate what case it was related to.

In T313446#8094343, @RoySmith wrote:

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

This may work on larger projects, but...not most of them. And the difficulty of setting up such a queue is a far larger scope than this ticket, and would likely require CU discussion and significant back-end work to get something like that functional. Email/IRC is much more efficient.

In T353938#9702532, @DannyS712 wrote:

@Dreamy_Jazz any chance that this can be prioritized by T&S during your ongoing work of CU?

(copying along to this task from the duplicate that got merged in)

The team will be taking a look at this next week.

The proposed idea is to do the following:

1. On Special:Investigate provide two block buttons, one for accounts and one for IPs. This means that the CU can use two different forms to block users and IPs without having to manually remove either the users or IPs for a particular use of the form.
2. This would also be done for Special:CheckUser 'Get users', by replacing the form with links to Special:InvestigateBlock with one for all users and one for all IPs. This would implement T329493: Replace Special:CheckUser's 'get users' block form with a usage of Special:InvestigateBlock
   1. Doing this means that we have one form for mass blocking users in CheckUser, which makes implementing feature requests related to it easier. Currently we have to modify two different forms (one for CheckUser and one for Investigate). This means that
   2. The InvestigateBlock form has more features and is easier to use. There are several issues with the 'Get users' block form, such as T314700: Restore the bottom paging links on 'Get users' and that submitting the form causes the CU to need to re-load the 'Get users' request, which links to Special:InvestigateBlock that prefill the targets would not bring.
3. We may warn if the user attempts to use Special:InvestigateBlock for both IPs and users.

Any thoughts and feedback on this would be appreciated.