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

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 or category.

These people are about to get blocked.


Proposed implementation
  • Checkbox for "Block this user from the whole site" is checked by default when navigating to Special:Block
  • On Special:Block, introduce a method to block a user/IP address/IP range from a specific page, category, or namespace
    • UI TBD — a new tab? checkboxes/dropdowns? potential wireframes below.
  • Block options should include:
    • Page and/or category name(s)
      • Existing pages/categories only, validation required in the input field.
      • Autosuggest selector?
      • Pages can be from any namespace
      • If a page or category is moved, the user should still be blocked from editing (e.g. block by page ID, not page name)
    • Namespace name(s)
      • Dropdown with existing, potentially like on RecentChanges
  • Block logs should display everywhere the current block displays (user page, Special:Block for the user, Special:Log, anywhere else?)
    • Log should include TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Foobar with an expiration time of N (reason) (unblock | change block)
  • When a user attempts to edit an applicable page, they should see a new type of block warning message which include 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 granular block is set, the checkbox for Prevent this user from editing his own talk page while blocked should be marked as disabled (unless they are blocking the User talk namespace).
  • Help tooltips for the new fields
  • Blocks can be overlapping (e.g. A user can be blocked from 'Rain' and 'Category:Weather')
  • If a category is provided, the blocked user cannot edit either the category page itself and all pages within the category.

Hyperlinks

Potential wireframes

We need to discuss these on-wiki to make sure they are understandable:

Location and labels of the items still TBD.

Details

Reference
bz674
There are a very large number of changes, so older changes are hidden. Show Older Changes
vvv added a comment.Sep 28 2008, 4:09 PM

Fixed in r41352.

matthew.britton wrote:

Why is this part of core? I concur with comment #3.

Reverted in r41405.

brion added a comment.Oct 1 2008, 8:13 PM

Some notes on the user_restrictions table schema:

  • If ur_type has two possibilities, why is it a VARBINARY up to 255 bytes long? I recommend making this an ENUM('namespace','page') if that's really what's needed.

Alternatively, just don't bother with the field. You could make the determination based on whether the title portion is present or NULL.

For instance replace:

ur_type
ur_namespace
ur_page_namespace
ur_page_title

with:

ur_namespace
ur_title

If ur_title is NULL, then it's a namespace-wide block.

If that seems to weird, then this would do fine:

ur_namespace <- NULL for title blocks
ur_page_namespace  <- NULL for namespace blocks
ur_page_title <- NULL for namespace blocks

The main reason to have a field would be to cleanly filter by type in a display list, in which case an ENUM would do just fine.

  • ur_user_text tinyblob NOT NULL,

Use a varchar(255) binary for this to match types elsewhere.

  • ur_reason tinyblob NOT NULL,

Consider not forcing this to TINY, we're thinking about relaxing length restrictions on various comment fields.

  • INDEX ur_user (ur_user,ur_user_text(255)),

There's no benefit to adding ur_user_text in this index. If there might be a need to display multiple blocks for a user in some sensible order, you should add that field here instead.

For lookups, consider whether a user might have many page-specific blocks affecting them. Do you want to load _every_ block against them, or just the ones relevant to a particular edit operation? In the latter case, it might be worth adding the namespace/title fields to the index.

  • INDEX ur_namespace (ur_namespace,ur_timestamp),

INDEX ur_page (ur_page_namespace,ur_page_title,ur_timestamp),

According to the MySQL manual... "When doing an ORDER BY, NULL values are presented first if you do ORDER BY ... ASC and last if you do ORDER BY ... DESC."

Eek! So you probably are going to want to limit your queries by ur_type for such ordered displays, in which case you should include it first in your index.

pgrawehr wrote:

Comment: It would probably be an advantage if the feature would use the ordinary block table (maybe with added fields), because that would improve the transparency from a users perspective. It's not practical if one has to check different logs to find out whether a user has been blocked completelly or using this new feature. At least the block log should be merged.

vvv added a comment.Dec 31 2008, 6:11 PM

Fixed in r45231.

brion added a comment.Dec 31 2008, 6:56 PM

Reverted for now in r45241

Unexpected schema changes in the middle of code review and run-up to 1.14 freeze

vvv added a comment.Jun 20 2009, 9:59 AM

Created attachment 6242
Proposed patch

Here's revised version of r45231.

Attached:

fridaesdoom wrote:

[21:57] <OlEnglish> too bad we can't set pending changes on a specific user..
[21:57] <OlEnglish> so that only that user's edits have to be verified

In #wikipedia-en OlEnglish had an idea of PC for a specific user's edits, if this were enabled we'd have an effective way of enforcing ARBCOM remedies in the form of editing restrictions, unlike PC I'd suggest that these edits aren't visible until approval. Thoughts?

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

john wrote:

Patch reviewed, it looks good for the most part (for being 2 years old), however I tend to agree that this should be implemented as an extnsion and not part of core.

This patch is a good place to start however.

werdna removed a subscriber: werdna.Dec 10 2014, 5:24 PM
AS added a subscriber: AS.Jun 18 2015, 10:15 AM

I see that some work has been started on this at Extension:PageBlock. It's still experimental, though.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 19 2015, 4:18 AM
Base added a subscriber: Base.Nov 9 2015, 10:41 PM
Scott added a subscriber: Scott.Nov 10 2015, 1:04 AM
Man77 removed a subscriber: Man77.Nov 28 2015, 9:49 PM

This is almost a short form Abuse Filter where the article_name is defined, the username or 'anon user name' known/definable, the actions definable (challenge, disallow, link addition/removal, lines_added). So rather than writing it through the AF criteria, we are defining the ready components, at the source place (rather than in AbuseFilter/nn) and have the ability to have it logged and recorded in a standard place (AbuseLog).

IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
DannyH updated the task description. (Show Details)Feb 5 2016, 11:48 PM
Meno25 removed a subscriber: Meno25.Feb 22 2016, 5:48 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.Jun 1 2017, 4:56 PM
TBolliger updated the task description. (Show Details)Jun 1 2017, 5:31 PM
TBolliger updated the task description. (Show Details)Oct 26 2017, 7:49 PM
TBolliger updated the task description. (Show Details)Mar 21 2018, 10:20 PM
TBolliger updated the task description. (Show Details)

I've begun some very preliminary and very basic wireframes at https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Per_user_page,_namespace,_category,_and_upload_blocking#Potential_wireframes for anyone interested in participating.

We'll start working on this project in earnest in the coming weeks.

TBolliger renamed this task from Allow users to be blocked from editing a specific article to Allow users to be blocked from editing a specific article or all articles inside a namespace or category..
TBolliger added a subscriber: jeremyb.
TBolliger added subscribers: Wong128hk, He7d3r, Matanya, RuyP.
TBolliger removed a subscriber: wikibugs-l-list.
TBolliger updated the task description. (Show Details)Thu, Apr 5, 4:44 PM
TBolliger updated the task description. (Show Details)Thu, Apr 5, 5:06 PM
TBolliger updated the task description. (Show Details)Thu, Apr 5, 5:25 PM
dbarratt updated the task description. (Show Details)Thu, Apr 5, 5:27 PM
TBolliger updated the task description. (Show Details)Thu, Apr 5, 5:34 PM
TBolliger updated the task description. (Show Details)Thu, Apr 5, 5:38 PM

Feedback for the wireframes:

  • The new options should be moved up under "Reason" so it is grouped with the other blacklist.
  • The "Namespace" field should be above the "Pages or Categories" field, this way it goes from most broad to least broad (Site → Namespace → Pages or Categories)

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

I don't see a reason why we wouldn't support IPs and IP ranges unless @TBolliger has a good reason not to?

TBolliger updated the task description. (Show Details)Mon, Apr 9, 8:45 PM

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

I don't see a reason why we wouldn't support IPs and IP ranges unless @TBolliger has a good reason not to?

Is there a significant difference in implementation if we want to support IP address and IP range blocks like this? I imagine not...

If there is no significant different in development complexity, then I think we should build it. It's better for IP usage to be socially enforced and for the technical ability to be available for any unforeseen use cases that may arise.

It certainly would be useful. If it's a single IP, we'll usually just block it. But, if an IP range is causing disruption, especially across several articles, admins may semi-protect all of the pages, shutting out innocent contributors. Unrelated users may even be in the same range (mobile provider, for instance), only they don't edit those specific set of articles, hence why we wouldn't want to block the whole range. I frequently run into this scenario. It is also common to use edit filters to prevent this sort of thing, which would become obsolete with the proposed feature.

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

I don't see a reason why we wouldn't support IPs and IP ranges unless @TBolliger has a good reason not to?

Is there a significant difference in implementation if we want to support IP address and IP range blocks like this? I imagine not...

If there is no significant different in development complexity, then I think we should build it. It's better for IP usage to be socially enforced and for the technical ability to be available for any unforeseen use cases that may arise.

I don't think there would be, we aren't changing how Blocks are matched, only how blocks are applied. You can still only have a single block for a user/ip/range.

Kghbln removed a subscriber: Kghbln.Fri, Apr 13, 3:10 PM