Allow users to be blocked from editing a specific article or all articles inside a namespace
Open, NormalPublic

Subscribers
Tokens
"Love" token, awarded by ToBeFree."Love" token, awarded by OlegCinema."Love" token, awarded by IKhitron."Love" token, awarded by MusikAnimal."Love" token, awarded by Wong128hk."Love" token, awarded by Liuxinyu970226."Love" token, awarded by MGChecker.
Assigned To
None
Authored By
bzimport, Oct 10 2004

Description

Problem to solve

Full site blocks are not always appropriate in all cases of user misconduct.


Proposed solution

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 could give admins the ability to block them from editing one specific page or all articles inside a namespace.


Acceptance criteria
  • 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:
    • If an admin specifies page(s) to block:
      • Page blocks can only be set for existing pages only, with validation required in the input field.
      • An autosuggest should help the admin find the correct page.
      • Pages can be from any namespace
      • 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)
    • If an admin specifies namespace(s) to block:
      • The input field should only accept valid namespaces, with validation required in the input field.
      • An autosuggest should help the user find the correct namespace.
  • Help tooltips should display for the new fields
  • Block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is partial:
    • Log for sitewide blocks should not change.
    • Log for page blocks should include TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Foobar with an expiration time of N (reason) (unblock | change block)
    • Log for namespace blocks should include TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace(s) Foobar with an expiration time of N (reason) (unblock | change block)
    • Log for both page and namespace blocks should include TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Foobar and namespace(s) Foobar2 with an expiration time of N (reason) (unblock | change block)
  • 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.
  • If a partial block is set, the checkbox for Prevent this user from editing his own talk page while blocked should be marked as disabled
  • 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

Hyperlinks

Designs


  • Technical Plan

    We'll allow the user (via the API or 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 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.

    Details

    Reference
    bz674

    Related Objects

    StatusAssignedTask
    OpenNone
    OpenNone
    DeclinedNone
    ResolvedTBolliger
    Resolveddmaza
    Resolveddbarratt
    DuplicateNone
    DuplicateNone
    Resolveddmaza
    Resolveddbarratt
    Resolveddbarratt
    Resolveddbarratt
    Resolveddbarratt
    Resolveddmaza
    Resolveddbarratt
    Resolveddbarratt
    ResolvedTBolliger
    OpenNone
    Opendmaza
    OpenTchanders
    OpenNone
    Opendbarratt
    Opendbarratt
    Opendbarratt
    DuplicateNone
    ResolvedTchanders
    ResolvedTchanders
    OpenPrtksxna
    OpenNone
    OpenNone
    OpenNone
    OpenNone
    Resolveddbarratt
    ResolvedTBolliger
    Resolveddbarratt
    ResolvedTBolliger
    ResolvedMooeypoo
    ResolvedMooeypoo
    ResolvedTBolliger
    Resolveddbarratt
    ResolvedTchanders
    ResolvedTBolliger
    Resolveddbarratt
    Resolveddmaza
    There are a very large number of changes, so older changes are hidden. Show Older Changes

    Hi @daniel โ€” Yes, the WMF's Anti-Harassment Tools team is current in development of this feature. We previously discussed our technical implementation on T193449: Draft a proposal for granular blocks table schema(s), submit for DBA review and reached some decisions with the database administrators. You can see the sub-tasks of this ticket for more specifics on how we will proceed with the project.

    We've been planning this project for several quarters now with @kaldari and other WMF engineering leadership and a technical RFC has never been suggested. We're adding to the existing block feature and our team's developers @dbarratt and @dmaza have planned it in a way to be easily undone if this functionality needs to be reversed. The vast majority of blocks will be set and performed the same way as they are today, but we're allowing admins to select more granularity if needed for the situation.

    @daniel: As Trevor mentioned, our current plan is to add some new functionality on top of how the existing blocks work without making major changes to that infrastructure (basically adding a new ipblock_options or ipblock_restrictions table and some new UI). If that seems like something worth further discussion with TechCom, or an RfC, let me know.

    @TBolliger & @alexhollender, doh! apparently it's Sitewide not Site-wide

    TBolliger updated the task description. (Show Details)Jun 18 2018, 5:25 PM

    @daniel: As Trevor mentioned, our current plan is to add some new functionality on top of how the existing blocks work without making major changes to that infrastructure (basically adding a new ipblock_options or ipblock_restrictions table and some new UI). If that seems like something worth further discussion with TechCom, or an RfC, let me know.

    Adding two new tables is not a trivial change. Is there a spec for the new system somewhere? How do we back out if it goes wrong? How does it work with logging?

    @daniel: As Trevor mentioned, our current plan is to add some new functionality on top of how the existing blocks work without making major changes to that infrastructure (basically adding a new ipblock_options or ipblock_restrictions table and some new UI). If that seems like something worth further discussion with TechCom, or an RfC, let me know.

    Adding two new tables is not a trivial change. Is there a spec for the new system somewhere? How do we back out if it goes wrong? How does it work with logging?

    Agile prefers executable specifications over a specification document. :) Although we have planned everything (errr... an MVP) out as subtasks to this tasks that will be (for the most part) executed from bottom to top on the Task Graph.

    However, to answer your question, we'll be adding one new database table and a new column to an existing table (See: T193449 and the patch in T197144). I think since this new table and column will only be used by this new feature, then we would back out by destroying the new table and the new column. This would change the blocks that were saved from being Partial Blocks back to Sitewide blocks. Alternatively we could first remove the partial blocks then delete the schema. Regardless, we'd need to notify the community what blocks were changed/removed.

    This feature also will not be rolled out on the train. Obviously the database changes will be, but any way to create a Partial Block (via Special:Block or via the API) will be behind a config flag. We'll first roll this out to test wiki and solicit testing from the community before testing on smaller production wikis. (please correct me if I'm wrong @TBolliger)

    brion added a comment.Jun 20 2018, 8:28 PM

    Just want to withdraw my old objections form very early discussion on this task; based on seeing the social dynamics of the projects over the years, this is indeed something likely to be useful in practice for enforcing per-topic bans etc.

    With my TechCom hat on:

    • For the database and API changes, it'd be great to have a quick summary of what's going to be changed and how it'll affect internals, deployment, and tools that manage blocks.
    • This is partially a 'product' sort of change to how the UI, API, and semantics of blocking work, so it'd be great to have a clear outline of what changes are expected, and to make sure that there's no surprises to how the site's changing.
    TBolliger updated the task description. (Show Details)Jun 20 2018, 9:07 PM
    dbarratt updated the task description. (Show Details)Jun 20 2018, 11:15 PM
    • For the database and API changes, it'd be great to have a quick summary of what's going to be changed and how it'll affect internals, deployment, and tools that manage blocks.

    As I mentioned in T2674#4303633, we'll be adding a table (ipblocks_restrictions) and a column to ipblocks (ipb_sitewide). The details can be found in T193449 and the patch is available in T197144.

    For the API Changes, we'll be updating API:Blocks and API:Userinfo(?) to list the details of the partial block T197141, edit endpoints will throw an appropriate error when an edit is made to a blocked page or namespace T197117, and updating API:Block to allow partial blocks to be set via the API T197111.

    • This is partially a 'product' sort of change to how the UI, API, and semantics of blocking work, so it'd be great to have a clear outline of what changes are expected, and to make sure that there's no surprises to how the site's changing.

    I would take a look at the mockups here:

  • Basically, we'll allow the user (via the API or 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 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.

    Of course the MVP T196578 is a restricted feature set. It will not be the full design changes and will only allow for blocking pages.

    Just want to withdraw my old objections form very early discussion on this task; based on seeing the social dynamics of the projects over the years, this is indeed something likely to be useful in practice for enforcing per-topic bans etc.

    With my TechCom hat on:

    • For the database and API changes, it'd be great to have a quick summary of what's going to be changed and how it'll affect internals, deployment, and tools that manage blocks.
    • This is partially a 'product' sort of change to how the UI, API, and semantics of blocking work, so it'd be great to have a clear outline of what changes are expected, and to make sure that there's no surprises to how the site's changing.

    Hi @brion ! This is 100% intended to be additive functionality for use in nebulous or difficult social circumstances when full site blocks are not appropriate. We will keep the existing functionality of sitewide blocks the same for blocks set via the API and the defaults on Special:Block will reflect the same defaults as today.

    Thank you @dbarratt, for the technical summary.

    During last week's the TechCom meeting, we came to the conclusion that this should go through the RFC process. RFCs are not just for complicated changes to existing things. They are also for adding new things that are then hard to undo (such as adding functionality to the public API, but also simple things like new kinds of log entries) or for things that come with considerable overhead (such as introducing DB tables) or impact core concepts: so far, user blocks could be seen as a revocation of permissions that are otherwise granted per user group (and may be required per namespace). As far as I understand, the feature defined here departs from that model. It seems prudent to have a broad discussion of this fact.

    As to executable specifications: they are good as acceptance criteria, but fail to capture justification of architecture decisions. One major reason for RFCs is to capture what alternatives were investigates and what tradeoffs where considered. It also provides an opportunity for a broader audience to raise concerns or propose alternatives. This is of course most useful before implementation starts.

    If you feel this has been sufficiently discussed and and speced out, there may be no need for discussion on IRC, and this could move to a last call right away. A concise writeup of what is going to be introduced and why would help with that.

    dbarratt updated the task description. (Show Details)Jun 25 2018, 5:21 PM
    dbarratt updated the task description. (Show Details)Jun 25 2018, 5:52 PM
    dbarratt updated the task description. (Show Details)Jun 25 2018, 6:00 PM

    Hi @daniel โ€” we're working with @kaldari to organize for your and TechComm's request for a technical RFC.

    putnik added a subscriber: putnik.Jul 5 2018, 2:57 PM

    For namespace blocks, it should be possible to specify a list of excluded pages. For example, if the user talk namespace is blocked, there should be able to exclude a pages of several admins that the user can ask, or page for requests to administrators for project namespace block.

    SPoore added a subscriber: SPoore.Jul 5 2018, 3:31 PM

    For namespace blocks, it should be possible to specify a list of excluded pages. For example, if the user talk namespace is blocked, there should be able to exclude a pages of several admins that the user can ask, or page for requests to administrators for project namespace block.

    @putnik Good idea. I can see that having one or more excluded pages could be useful in several workflows.

    IKhitron added a subscriber: IKhitron.
    OlegCinema added a subscriber: OlegCinema.EditedJul 12 2018, 2:18 AM

    I also think that it would be quite good to forbid the creation of pages from a namespace, but not their editing. It can be sometimes useful. For example, if the participant has no to create articles, but corrects spelling errors in others.

    For our initial implementation of this project we're going to keep it simple โ€” allowing sub-actions within a namespace/category/topic is pretty niche for what we're trying to accomplish in the short-term.

    I do agree that "page creation" should probably be a separate option to block, such as uploading files.

    TBolliger added a comment.EditedJul 13 2018, 11:02 PM

    @daniel โ€” I owe you an update. Between summer vacations and prep for Wikimania our bandwidth is limited, but we are still planning submit a TechCom RFC. We are aiming to have it ready for you by July 25.

    Marshmallych added a subscriber: Marshmallych.EditedJul 16 2018, 2:08 PM

    I think, partial blocks are needed for perform topic-bans, and adding more features which block some actions are necessary instead of full block.

    I think, partial blocks are needed for perform topic-bans, and adding more features which block some actions are necessary instead of full block.

    Partial blocks will certainly be one tool to help enforce topic bans, but there will still be need for socially enforced methods, as "broadly construed" is too difficult to capture in a block.

    Just a suggestion, but maybe a whole separate log for these "blocks" could be created called "Restrict logs" where other than "Blocks" "Restrictions" are listed, as for the suggestion to create restrictions on Wikimedia Commons users to only be able to upload files of course editing "File:" Belongs to that as these files might need to be recatrgorised. Maybe for sysops a button separate for "block" and "restrict" could also be created.

    In this scenario block logs would only record full sitebans and restrict logs restrictions from certain spaces or abilities (e.g. Uploading files, creating new pages, editing certain name spaces). Also this would be beneficial for users with interaction bans as then neither party could edit each other's user talk pages.

    Addendum: As in my above suggestion "Block" and "Restrict" would be teo different settings (maybe even using a separate API) these could both be in effect at the same time without affecting the other as with the above example relating to the Utah editing restrictions.

    I think, partial blocks are needed for perform topic-bans, and adding more features which block some actions are necessary instead of full block.

    Partial blocks will certainly be one tool to help enforce topic bans, but there will still be need for socially enforced methods, as "broadly construed" is too difficult to capture in a block.

    What do you mean difficult? If you are going to make this tool, so take the trouble to make it good and in full force, not "I can't, it's hard", sorry.

    What do you mean difficult? If you are going to make this tool, so take the trouble to make it good and in full force, not "I can't, it's hard", sorry.

    Sure, let me explain what I mean by 'difficult' using the example of a topic block about religion.

    A partial block could be set against the articles about religion (religion, christianity, hinduism, islam, etc.) and T190349 could introduce the ability to block anything within categories about religion (Category:Religion, Category:History of religion, etc.). If the user creates troublesome new pages they could be blocked from creating new pages.

    It become more difficult to proactively enforce on articles not within these categories, or within weakly related categories. The article about Tom Cruise belongs to several Scientology related categories, but the banned user should still be allowed to edit about Tom's acting career. The article about the actor Michael Cera does not belong to any religion related categories, but the banned user could add information about Michael's religious views against the ban.

    It has been suggested that we expand AbuseFilter to focus on filtering editing for certain users as opposed to certain pages/namespaces/actions, but our software developers estimated that such a project would take well over a year to build, with partial blocks taking significantly less time. Our Anti-Harassment Tools team has other priorities in addition to this project.

    TBolliger updated the task description. (Show Details)Jul 18 2018, 2:18 PM
    TBolliger updated the task description. (Show Details)Jul 18 2018, 2:32 PM

    During last week's the TechCom meeting, we came to the conclusion that this should go through the RFC process.

    RFC ticket here: T199917: RFC: Block users by page, namespace, and/or action (Partial Blocks)

    Thank you.

    Also, here I suggest:

    * 16:01, 22 May 2018 Tegel (talk | contribs) blocked Brion VlBER (talk | contribs) with an expiration time of indefinite (account creation blocked) (Vandalism)
    * Block parameters: 
    ** Editing: User talk:Tegel, User:Brion VIBBER, Manual:DefaultSettings.php
    ** Account creation
    ** Moving pages
    ** Upload files
    Huji added a subscriber: Huji.Aug 5 2018, 7:55 PM

    I expressed this on meta too, and am copying it here as well:

    Imagine a user is indef blocked from editing in Wikipedia namespace, because of a history of disruptive edits in that namespace. Then that user insults someone else on their talk page, so I decide to block them everywhere for 1 week. I go ahead and change the block settings accordingly. At the end of the one week, the user will be unblocked everywhere.

    This is an important side effect of the "one block per user" idea, which is part of this proposal. Instead, we should allow for multiple blocks per user. That way, I would add a *new* one-week block for all namespaces, and at the end of it only that block will expire, while the other namespace-specific indef block will continue to exist.

    @Huji I completely understand the use-case and I agree that this is a problem that needs to be resolved. We created T194697 and after some investigation, we discovered that it's effectively a completely separate project that has no relation to this project at all. The only relationship is that... it's somewhat pointless to create multiple sitewide blocks for the same user/ip. We could do T194697 before doing this project, but what would be the point? At the same time, adding T194697 to this project constitutes scope creep since there isn't any overlap between the two. The irony is that this task (as well as T104099 & T6995 which are also separate projects) exposes the multi-block issue that wasn't a problem before. We are effectively creating a new problem (and perhaps that's not a bad thing).

    A slight mitigation to this issue will be that we will preserve the existing pages/namespaces that were specified when switching between a sitewide and partial block. I realize this doesn't fix the multipile expiry issue, but at least you'll be able to manually go in and switch between the two without having to re-specify the pages every time. The work-around would therefore be to update the indefinite partial block to an indefinite sitewide block, and then manually switch them back to partial at the end of the week. I understand that this is far from ideal.

    Huji added a comment.Aug 7 2018, 6:10 PM

    I completely understand.

    But let's think about it this way. The current task says "replace the bedroom carpet". T194697 says "the pipes passing under the bedroom are slowly leaking". These are two separate issues, but if we are going to bring contractors in (akin to: have developers refactor this part of the code), I guess it is best to fix both issues at the same time.

    If we fix this first and fix T194697 later, we will have to peel the carpet again (akin to: refactor the blocking interface again) once we enable multiple blocks, or use any other alternative solution. You could say "but I don't have enough money to pay for contractors for both jobs right now, and that is why they have been both waiting for so long" (akin to: we cannot dedicate development time to both of these tasks, and that is why they have been waiting for several years each), and I would understand. But I would hate to see the new carpet being torn apart.

    TBolliger added a comment.EditedAug 7 2018, 6:59 PM

    We'll tackle T194697 after T2674, it's merely a question of sequencing. We likely won't release this on any large wikis until T194697 is complete.

    abian added a subscriber: abian.Aug 12 2018, 9:03 AM
    ToBeFree added a subscriber: ToBeFree.
    dbarratt updated the task description. (Show Details)Aug 22 2018, 3:27 PM
    -jkb- removed a subscriber: -jkb-.Sep 7 2018, 9:50 PM