This RFC is an extension of the project called Partial Blocks (T2674). This RFC includes work under the partner-project called Multi-blocks (T194697) but is separate from the RFC for Partial Blocks (T199917).
Project goals
Our goal is to give wiki administrators a more robust set of tools to be able to better respond to different user conflict situations. To retain constructive contributors who cause disruption on one page (e.g. contentious article page, user talk page of someone they constantly berate, etc.) we want to give admins the ability to block them from editing specific pages and/or all articles inside a namespace. That work was called Partial Blocks.
Multiblocks is an improvement on and extension of the Partial Blocks feature. They are closely related but provide slightly different abilities. Today, there are only sitewide blocks and only one block per user. Partial Blocks gives admins the ability to create blocks for a page, action, or namespace.
Multiblocks then allows an admin to create multiples of these that may overlap in various ways. These provide a lot of flexibility to an admin to deal more humanely with editors that whose actions run contrary to community guidelines.
Hyperlinks
- Project page on Meta
- T194697 — Primary phabricator task of prioritized work for Multi-blocks
- T202322 — Database proposal phabricator tasks for Multi-blocks
- T190350 — Larger epic ticket including both prioritized and unprioritized work
Product requirements
This list is annotated for brevity, see the full list at T194697. UI designs are currently in progress.
- Admins will be able submit a new block on Special:Block or via API which should not affect any existing block. Each block can contain different parameters & independent expiration dates.
- Admins will be able to see all active blocks set against a user/IP on Special:Block, and be able to select one to modify its parameters.
- Admins will be able to update existing block entries via API.
- Special:Block will allow for prefilling with a block entry and its parameters via URL parameter.
- 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
- Special:BlockList will show one row for every block entry.
Technical Plan
We are tracking technical plans specific to Multiblocks here: T201692.
- Structural Changes:
- Draft a proposal for mutliblocks table schema(s) and get consensus T202322
- Create Migration Plan from old schema to new schema T202572
- Create New schema for multiblocks
- Create new classes in order to work with Multiblock in an abstracted way (and ensure all the existing tests pass)
- Idea: Create BlockTarget that gets a block a target with all of the blocks.
- Idea: Block "entry" is an existing Block class
- Idea: Create a MergedBlock that returns all of the block entries merged together
- New classes must understand and respond to current "Is this user blocked?" kind of request (There are two kinds of requests that do this: Pre-flight check or hard check.)
- Implementation Changes:
- Update block notices (desktop, mobile, etc.)
- Might be merged and then give more details (split into separate entries), etc.
- Update Special:BlockList with Block Entries
- Update Block APIs
- UserInfo should return a merged block
- Blocks should return all of the block entries, perhaps in an order where the first one is the most restrictive (i.e. a sitewide block)? or perhaps the order doesn't matter
- Update PHP APIs to create Multiblocks
- Update API:Block to set Multiblocks
- Update Special:Block and Special:Unblock to set and unset Multiblocks
- Ensure that Autoblocks work properly
- Copy all of the block settings?
- New Target?
- Update block logs with mutli-block details
- Add Links to Special:Block (and the block notices?) to edit specific Block Entry on Special:Block
- Remove old schema for single block
- Update block notices (desktop, mobile, etc.)
FAQ
Why make this a part of Block instead of creating another thing (i.e. "Partial Block")?
If we were to create a new tool a lot of the existing functionality would be duplicated. Not only is this a lot of duplication of existing functionality and code, it is confusing for new admins to have to different pages to block a user.
Why make this part of core and not a new extension?
Effectively, because Block is in core. The UX should be well integrated into the existing Block workflow. Alternatively, it is certainly possible to implement this feature as an extension, but many new hooks will need to be created in order to make the necessary modifications to the existing Block workflow. Another alternative would be to pull Block out of core completely into its own extension.
What will happen to sitewide blocks?
Sitewide blocks will still work just as they do today. Sitewide blocks will always take precedence over any partial blocks that an admin might create. In fact, with the advent of multiblocks, an admin has great flexibility in blocking parts of the site for a long period but then using a sitewide block for a short time. The longer, more specific blocks would still be in place when the sitewide block expires.
What happens if there are blocks whose pages, namespaces, and/or expirations overlap?
The most important aspect of blocks is that the intended target should not be able to edit content in question. Overlapping blocks are the biggest benefit for multi-blocks and every block entry will be enforced. Whatever pages, namespaces, or actions should be inaccessible will stay inaccessible until the provided expiration date for that block entry. Each block will be removed at its own independent expiration date.
What if there are two of the exact same block created at the exact same time by two different admins?
In effect, there’s no such logical idea as a double-block so both blocks would prevent the user from doing the action or accessing the page until they both expire at the same time. In database terms, there’s no uniqueness between these blocks and the database will happily handle both of them. Additionally, the code that blocks the users will not have an issue enforcing the blocks correctly in this situation.
How will admins know which blocks exist for a user or a page or something else?
We will be updating all pages such as Special:BlockList to handle the increased amount of information that will now exist about blocks. Admins will have similar edit and creation tools as they do for blocks today but with additional functionality should they choose to use it.
Product plan
The WMF's Anti-Harassment Tools team plans to build the following in the second-half of 2018. Changes required for this functionality are detailed in this RFC ticket:
- With extremely high certainty:
- With medium certainty:
If partial blocks is a roaring success we may consider future enhancements to blocking. I (@TBolliger) feel this is extremely unlikely because of local maximums available for partial blocking — pages, categories, and action blocking will cover the majority of the use cases, and our team has other priorities. The most commonly requested blocking functionality that we've prioritized low (for design, technical, and/or social reasons) are T100070, T201853, T190349 or T194804, T202159, or T27400.