Here's my proposal.

At the top of Special:Block, show a table or list of blocks for the specified target. Highlight the block being edited. Clicking on a different item in the list causes the other block to be edited. At the end of the list, there is a "new block" item which allows a new block to be created. An unblock button should be added, allowing blocks to be deleted from this form.

IP address or username:
[Some User_____________________________] [Search]

Blocks for this user:

• 10:00, August 9, 2018 A block created with some reason
• 09:39, August 9, 2018 A second block created with some other reason
• Add new block

Expiration:
[____] [_______________________________] [_______________________________]
Reason:
[Other____v]
[Some other reason______________]

• Block account creation
• Block user from sending email
• Prevent this user from editing their own talk page while blocked
• Autoblock any IP addresses used (includes cookie block)
• Watch this user's user and talk pages

[Unblock] [Update block]

Special:Block should optionally take an id parameter (ipb_id). It would show the form as above with the relevant block selected. The "change block" links on Special:BlockList would then link to Special:Block with a specific ID.

Special:Block with a wpTarget parameter would go to this form with the most recent block selected for editing. If there are no blocks for the given user, "Add new block" would be the only list item and would be selected.

The unique index in the ipblocks table was added by me in 1d9922db6442dec82e4be07c45c2e8a3a2035602 to address the case where two or more admins race to block a vandal. The insertions typically occur within a few seconds of each other. Admins complained that the previous behaviour, allowing duplicate blocks, was confusing and unacceptable. But we don't want to denormalise the proposed partial block schema in order to include all options in the unique index.

Instead we should split the ipblocks table into block_target and block_entry:

CREATE TABLE block_target (
  bt_id int NOT NULL PRIMARY KEY AUTO_INCREMENT,
  bt_address tinyblob NOT NULL,
  bt_user int unsigned NOT NULL default 0,
  bt_auto bool NOT NULL default 0,
  bt_range_start tinyblob NOT NULL,
  bt_range_end tinyblob NOT NULL,
  bt_count int NOT NULL default 0
);

CREATE TABLE block_entry (
  be_id int NOT NULL PRIMARY KEY AUTO_INCREMENT,
  be_target int NOT NULL,
  be_by int unsigned NOT NULL default 0,
  be_by_text varchar(255) binary NOT NULL default '',
  be_by_actor bigint unsigned NOT NULL DEFAULT 0,
  be_reason varbinary(767) NOT NULL default '',
  be_reason_id bigint unsigned NOT NULL DEFAULT 0,
  be_timestamp binary(14) NOT NULL default '',
  be_anon_only bool NOT NULL default 0,
  be_create_account bool NOT NULL default 1,
  be_enable_autoblock bool NOT NULL default '1',
  be_expiry varbinary(14) NOT NULL default '',
  be_deleted bool NOT NULL default 0,
  be_block_email bool NOT NULL default 0,
  be_allow_usertalk bool NOT NULL default 0,
  be_parent_block_id int default NULL
);

The unique index would be on block_target (bt_address, bt_user, bt_auto). When the number of blocks for a given target goes from zero to one, the block_target row would be inserted. A duplicate key error in this insertion would then provide the trigger for displaying a conflict warning to the admin. Adding extra blocks to a target would need to lock the block_target row, to prevent the row from being deleted while the new block_entry row referencing it is inserted. This could be done by having a statistics field, say block_target.bt_count. Updating it with UPDATE block_target SET bt_count=bt_count+1 WHERE ... would lock the row, preventing deletion. The INSERT INTO block_entry would then be done in the same transaction. On expiry or unblock, the DELETE could be done with WHERE bt_count=0 for extra safety.

• What do we add to Special:Contributions to indicate that there are multiple blocks in effect?

Currently we show a block log snippet with "unblock" and "change block" links. That's probably fine. Ideally the "change block" link created by the log formatter would use the ID instead of wpTarget so that the correct block would be selected.

We could show the full block list, similar to the block lists I'm proposing for Special:Block and Special:Unblock, but I don't think it's a requirement. Currently we don't show any actual blocks, just the log entry.

• Does Special:Unblock remove all blocks? (it currently does not show a log, maybe it should?)

Show a block list with checkboxes. Start with all boxes checked.

@tstarling wow thanks for your detailed comment!

I like the database schema changes, it looks like the way it should be, but it also looks like a big change, so I've been afraid to make that big of a change.

My only UX feedback would be that each block's form fields should be exposed on the page (and clicking "Add" would use JS to add a new set of fields to the page). That way you can modify more than one block at a time and get a complete picture of what is going on. But I'm interested to hear what @alexhollender thinks. :)

Thank you Tim!

@dbarratt @dmaza — we should start thinking about our database schema proposal to implement multi-blocks to go through DBA review and TechCom RFC _before_ we start building.

We have a meeting with @alexhollender next Thursday about this exact subject. We'll discuss more about our UX design timeline then.

I have a couple questions regarding the schema.

1. Is there a reason why bt_auto exists in block_target instead of block_entry. It feels to me that autoblocks can be just another entry
2. What is the use for be_parent_block_id in this new design?

In T194697#4492140, @dmaza wrote:

1. Is there a reason why bt_auto exists in block_target instead of block_entry. It feels to me that autoblocks can be just another entry

I agree.

1. What is the use for be_parent_block_id in this new design?

I don't think it should be necessary anymore.

In T194697#4492140, @dmaza wrote:

1. Is there a reason why bt_auto exists in block_target instead of block_entry. It feels to me that autoblocks can be just another entry

Because, for privacy, you can't search for an autoblock entry by IP address or otherwise see the IP address the autoblock is associated with. If an admin blocks an IP address that already has an autoblock associated with it, it's a privacy violation to show the autoblock on the same list with the manual block. Currently, unblocking or modifying an autoblock can only be done by ID using a "#" prefix. So it is more like a kind of target than a block option.

But for efficiency at save time, it's necessary to be able to search the database for autoblocks by IP address. So you can't just use the autoblocked user as the target.

When a user is blocked, an autoblock is immediately inserted for their last IP address. So without privacy protections, the autoblock feature could be used to provide the IP address of any editor, by temporarily blocking them. This could have a significant impact especially for small wikis where there is no effective oversight of admins.

I've moved the schema discussion to T202322: Draft a proposal for multiblocks table schema(s) and get consensus, please continue the conversation on the schema there. :)

This project has been deprioritized by the WMF's Anti-Harassment Tools team until further notice. We want to finish Partial Blocks and re-evaluate if this functionality (which is expensive to build) is actually necessary.

I would rather tackle T208175 first anyways and see if that resolves most of the original use case(s).

In fact, with T208175, it might be somewhat trivial for someone to make a bot that would rollback a block to a previous state after it's expired (or something like that).

Is there any progress on this?
I have just had an issue with a user indefinitely blocked from the Wikipedia namespace: I blocked him sitewide for an hour, I had to restore his Wikipedia namespace block right after.
This is not an expected behaviour at all. A sitewide block was due to an additional rule violation in a different namespace, and this is definitely not a good reason to remove the indefinite Wikipedia namespace block.
As is, an AbuseFilter is a better solution than a partial block: I would also need two actions (full block, edit AbuseFilter VS full block, restore namespace block) but the solution would be permanent.

Hi, is there any progress on this? This task is now open for over two years, but nothing happened so far. It can't take years to program that several blocking parameters are possible at the same time.

In T194697#6496818, @Toni_Mueller wrote:

Hi, is there any progress on this? This task is now open for over two years, but nothing happened so far. It can't take years to program that several blocking parameters are possible at the same time.

There still hasn't been anyone willing to take this on.

Work on this probably shouldn't start until the TechCom-RFC at T202673 is complete