The Wikimedia Foundation's #anti-harassment Tools team would like the Wikimedia #techcom to review our implementation plans for our project of Partial Blocks.
Thank you!
----
====Project goals
The goal of the Partial Blocks project 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.
------
====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
* T193449 — Database Admin proposal and discussion Phab task
* T190350 — Larger epic including both prioritized and unprioritized work
----
====Product requirements
//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:
** 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), for a page, for a namespace, or for a page + namespace.
* The block should be listed and annotated on Special:BlockList, per the designs
* 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, expiration, etc.)
* Only one block per user (like it is today) — to update the block, admins will need to modify the block.
* 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 be ignored
------
====Technical Plan
- Schema Changes. 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 ]]
- 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
We'll allow the user (via the API or [[ https://www.mediawiki.org/wiki/Help:Blocking_users | Special:Block ]]) to set the `ipb_sitewide` flag (a boolean) and then specify the pages or namespaces they want to restrict, which will be stored in `ipblocks_restrictions`. The restrictions will need to be listed anywhere we currently list the blocks (Special:BlockList, Block Log, Contributions, etc.). We'll also enforce the block by modifying [[ 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. Finally, we'll update the block notices the user gets so that it is page specific.
------
====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 blocked. Not only is this a lot of duplication of existing functionality, 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, but that is outside the scope of this issue.
------
====Future work
Depending on the effectiveness of this project (decreasing harassment and user misconduct while retaining contributors) and community response, we plan to add other types of partial blocking, potentially including:
* {T6995}
* {T194529}
* {T199918}
* {T190349}