The Wikimedia Foundation's #anti-harassment Tools team would like the Wikimedia #techcom to review our implementation plans for our project of Partial Blocks.Extending Block Capabilities. This RFC was originally begun for a subset of this project called Partial Blocks (T2674). 🆕 This updated version now includes work under the partner-project of Multi-blocks (T194697.)
Thank you!
----
====Project goals
The goal of the Partial Blocks projectOur 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
* [[https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking|Project page on Meta]]
* T2674 — Primary phabricator task of prioritized work for Partial Blocks
* T194697 — Primary phabricator task of prioritized work for Multi-blocks
* T193449 — Database proposal phabricator task for Partial Blocks
* T193449* T202322 — Database Admin proposal and discussion Phab taskphabricator tasks for Multi-blocks
* T190350 — Larger epic ticket including both prioritized and unprioritized work
----
====Product requirements
**Partial blocks**
//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`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)
* The block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is sitewide (appear as-is today)* Actions include uploading files, for amoving pages, for a namespace,and creating pages. or for a page + namespaceThese options will be disabled when the sitewide radio button is selected.
* * The block should be listed and annotated onlog entries on Special:Contributions, Special:BlockList, perand Special:Log should be indicate if the designsblock is sitewide (appear as-is today) or partial.
* When a user attempts to edit an applicable page, they should see a new type of block warning message using a new string key which includes information on their block (reason, expirationThe block should be listed and annotated on Special:BlockList, etc.)per the designs
* Only one block per user (like it is today) — to update the blockWhen 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, admins will need to modify the block.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
**Multi-blocks**
//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
- Schema ChangeMuch of the work detailed below was done to implement Partial Blocks. After this RFC is concluded, our team plans to release Partial Blocks to production before Multiblocks even though the work is related. As part of extending this work with Multiblocks, we are tracking technical plans specific to Multiblocks here: T201692. The new plans for schema changes are coming together in T202322.
**Partial Blocks**
- 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 [[ https://www.mediawiki.org/wiki/Manual:Ipblocks_table | ipblocks ]]
-- Create tables for entry, target, and restrictions
- PHP API Changes
-- Allow `restrictions` to be get/set on a `Block` T197114
- Action API Changes
-- Update [[ https://www.mediawiki.org/wiki/API:Blocks | API:Blocks ]] and [[ https://www.mediawiki.org/wiki/API:Userinfo | API:Userinfo ]](?) to list the details of the partial block T197141
-- [[ https://www.mediawiki.org/wiki/API:Edit | Edit endpoints ]] will throw an appropriate error when an edit is made to a blocked page or namespace T197117
-- Update [[ https://www.mediawiki.org/wiki/API:Block | API:Block ]] to allow partial blocks to be set via the API T197111
- Block Enforcement
-- Modify [[ https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/user/User.php;83c9efb5b9ddf52163c77dedaa710db3a3ec9d80$2283 | User::isBlockedFrom() ]] to check if the block is sitewide or not and if not to check to see if the page is on the restrictions list. T197117
- UI Changes
--- Update [[ https://www.mediawiki.org/wiki/Help:Blocking_users |te Special:Block ]] to allow users to specify whether a block is sitewide or partial. If partial, they will be allowed to specify the pages, If partialactions, they will be allowed to specify the pages/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
**Multi-blocks**
- Structural Changes:
-- Draft a proposal for mutliblocks table schema(s) and get consensus T202322
-- Create Migration Plan from old schema to new schema (add links to ticket)
-- 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
------
====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 at `Special:PartialBlock` a lot of the existing functionality between Block and Partial Block would be duplicated. There would not only be a separate page to create the block, but also a separate list of blocks `SpecialPartialBlockList` as well as a separate log. New, effectively duplicate API endpoints would need to be created to create and list partial blocks. Lastly, there would also need to be distinct block notices for users who are partially blockwould 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 bebut many new hooks will need to pull //Block// out of core completely into its own extension,be created in order to make the necessary modifications to the existing Block workflow. but that is outside the scope of this issueAnother alternative would be to pull Block out of core completely into its own extension.
------**What will happen to sitewide blocks?**
====Product plan
With extremely high certaintySitewide 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, the WMF's Anti-Harassment Tools team wmore specific blocks would still build the following ie in place when the second-half of 2018:itewide block expires.
* {T2674}
* {T6995}**What happens if there are blocks whose pages, namespaces, and/or expirations overlap?**
* {T194697}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.
Depending on the effectiveness of this project (decreasing harassment and user misconduct while retaining contributors) and community response**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, we plan to add other types ofthe code that blocks the users will not have an issue enforcing the blocking in 2018/2019:s correctly in this situation.
* {T194529}**How will admins know which blocks exist for a user or a page or something else?**
* {T199918}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.
------
* {T100070}====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:
If partial blocks is a roaring success we may consider future enhancements to partial 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 partial blocking functionality that we've prioritized low (for design, technical, and/or social reasons) are* With extremely high certainty:
*** {T201853}674}
* The biggest open question is about topic blocks, which could use categories (T190349), Wikiprojects or ORES classification (T194804.)* {T6995}
** {T194697}
* With medium certainty:
* {T202159}** {T194529}
* {T27400}** {T199918}
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.