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.
- Project page on Meta
- T2674 — Primary phabricator task of prioritized work for Partial Blocks
- T193449 — Database proposal phabricator task for Partial Blocks
- T190350 — Larger epic ticket including both prioritized and unprioritized work
This list is annotated for brevity, see the full list and UI designs at T2674
- On Special:Block, add a radio button to select setting the block as sitewide vs. partial.
- When a block is saved with the sitewide radio button selected, the block should behave exactly as it does today.
- If the partial radio button is selected, the admin should be able to provide a list of pages and/or namespaces as well as selecting checkboxes for actions:
- Page blocks can only be set for existing pages in any namespace, with autosuggest and validation in the input field.
- Namespace blocks can only be for valid namespaces, with autosuggest and validation in the input field
- If a page is moved or deleted, the user should still be blocked from editing that page (i.e. block by page ID, not page name)
- Actions include uploading files, moving pages, and creating pages. These options will be disabled when the sitewide radio button is selected.
- The block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is sitewide (appear as-is today) or partial.
- The block should be listed and annotated on Special:BlockList, per the designs
- When a partially blocked user attempts to edit an applicable page, they should see a block warning message using a new string key which includes information on their block (reason, expiration, etc.)
- The Block API should be updated to support all partial block functionality
- Sitewide blocking via API should not change
- API documentation should be updated
- If a partial block is set via API, invalid pages and namespaces should throw an error
After this RFC is concluded, our team plans to release Partial Blocks to production before Multi-blocks even though the work is related.
- Schema Changes for Partial Blocks. The details can be found in T193449 and the patch is available in T197144.
- Add table ipblocks_restrictions
- Add column ipb_sitewide to ipblocks
- PHP API Changes
- Allow restrictions to be get/set on a Block T197114
- Action API Changes
- Block Enforcement
- UI Changes
- Update Special:Block to allow users to specify whether a block is sitewide or partial. If partial, they will be allowed to specify the pages, actions, and/or namespaces to block. T197109
- Update Block Notices with partial block details T197117
- Ensure that mobile block notices are page specific T197122
- Update Block Log & Special:BlockList T197143 with partial block details. T197108
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.
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. 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.
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.