Multiblocks — Allow for multiple, simultaneously blocks with different expiration dates.
Open, NormalPublic

Description

After T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace there may be reason for a user to have several blocks with different expiration dates. For example:

User:Apples has been indefinitely blocked from editing Neptune. They then receive a 24 hour full-site block. When the full site block expires, they should continue to be blocked from Neptune.

or

User:Bananas is indefinitely blocked from editing Mars and from editing Venus until 2025. An admin wants to block them from Saturn for one month.

This is easy to manually set for simple granular blocks but becomes more troublesome if the user is blocked from several pages, categories, namespaces, and/or actions.


Requirements

  • Adding a new block should not affect any existing block.
  • Each block can contain different parameters & independent expiration dates.
  • Admins will need to see all active blocks set against a user/IP on Special:Block.
    • Admins will be able to select an active block and modify its parameters.
  • Admins will be able to remove one, several, or all blocks from Special:Unblock.
  • Users will be able to see all their active blocks on Special:Contributions
  • Users will be able to see all blocks on Special:BlockList (searching/filtering will be handled on another ticket, to be filed.)

Designs

Version here: https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking/Multi-blocks

TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.May 18 2018, 1:46 PM
TBolliger renamed this task from If a granularly-blocked user receives a full site block, the granular block should resume at the expiration of the siteblock to Multi-blocks — Allow for multiple, simultaneously blocks with different expiration dates..May 31 2018, 9:40 PM
TBolliger triaged this task as Normal priority.
TBolliger updated the task description. (Show Details)
Vvjjkkii renamed this task from Multi-blocks — Allow for multiple, simultaneously blocks with different expiration dates. to 2ycaaaaaaa.Jul 1 2018, 1:10 AM
Vvjjkkii raised the priority of this task from Normal to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot lowered the priority of this task from High to Normal.
CommunityTechBot renamed this task from 2ycaaaaaaa to Multi-blocks — Allow for multiple, simultaneously blocks with different expiration dates..
CommunityTechBot added a subscriber: Aklapper.
TBolliger renamed this task from Multi-blocks — Allow for multiple, simultaneously blocks with different expiration dates. to Allow a way for a partial block to be reinstated after a sitewide block expires (multi-blocks or other system).Aug 6 2018, 5:54 PM
tstarling added a subscriber: tstarling.EditedAug 9 2018, 1:01 AM

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. :)

TBolliger added a subscriber: dmaza.Aug 9 2018, 4:29 PM

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.

dmaza added a comment.Aug 9 2018, 4:41 PM

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

tstarling added a comment.EditedAug 11 2018, 11:43 PM
  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.

TBolliger renamed this task from Allow a way for a partial block to be reinstated after a sitewide block expires (multi-blocks or other system) to Multi-blocks — Allow for multiple, simultaneously blocks with different expiration dates..Aug 16 2018, 9:27 PM
TBolliger updated the task description. (Show Details)
dbarratt renamed this task from Multi-blocks — Allow for multiple, simultaneously blocks with different expiration dates. to Multiblocks — Allow for multiple, simultaneously blocks with different expiration dates..
TBolliger updated the task description. (Show Details)Sep 21 2018, 5:09 PM

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