Page MenuHomePhabricator

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

Assigned To
Authored By
bzimport
Oct 10 2004, 6:28 PM
Referenced Files
F18843240: granular-form-options.jpg
Jun 6 2018, 5:58 PM
F18843238: block-user.jpg
Jun 6 2018, 5:58 PM
F17619357: Screen Shot 2018-05-01 at 1.29.35 PM.png
May 3 2018, 5:53 PM
F16720065: Screen Shot 2018-04-05 at 1.22.12 PM.png
Apr 5 2018, 5:25 PM
F16720064: Screen Shot 2018-04-05 at 1.22.48 PM.png
Apr 5 2018, 5:25 PM
F1404: restrictUser.patch
Nov 21 2014, 7:08 PM
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.

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

    StatusSubtypeAssignedTask
    ResolvedTheDJ
    Resolved TBolliger
    DeclinedNone
    Resolved TBolliger
    Resolveddmaza
    Resolveddbarratt
    DuplicateNone
    DuplicateNone
    Resolveddmaza
    Resolveddbarratt
    Resolveddbarratt
    Resolveddbarratt
    Resolveddbarratt
    Resolveddmaza
    Resolveddbarratt
    Resolveddbarratt
    Resolved TBolliger
    Resolved TBolliger
    Resolveddmaza
    ResolvedTchanders
    ResolvedNone
    Resolveddbarratt
    Resolveddbarratt
    Resolveddbarratt
    DuplicateNone
    ResolvedTchanders
    ResolvedTchanders
    DeclinedNone
    DeclinedNone
    Resolved aezell
    ResolvedNiharika
    Resolveddbarratt
    Resolved TBolliger
    Resolveddbarratt
    Resolved TBolliger
    ResolvedMooeypoo
    ResolvedMooeypoo
    Resolved TBolliger
    Resolveddbarratt
    ResolvedTchanders
    Resolved TBolliger
    Resolveddbarratt
    Resolveddmaza

    Event Timeline

    There are a very large number of changes, so older changes are hidden. Show Older Changes

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

    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.

    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.

    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.

    @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.

    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.

    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

    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.

    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.

    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.

    Krinkle subscribed.

    (TechCom triage note: sub task T204991 has had implementation work begin, at https://gerrit.wikimedia.org/r/470656.)

    TBolliger claimed this task.

    This is done and live on production! There are some follow-up tasks that may linger for a while, but I will close this task to mark the primary development of this functionality as 🎆 complete! 🎇