Allow users to be blocked from editing a specific article


Author: elian

Give Sysops the ability to block a user from editing a specified article.

This feature request is related to the growing problems in wikipedia with
controversial articles. A user ban is a harsh measure and is subjected to a lot
of discussion. Often there are only a few articles where the edits of one user
are problematic.

The feature could (and should) be used following judgements from the arbitration
committee or similar instances on other wikis.

Version: unspecified
Severity: enhancement

This card tracks a proposal from the 2015 Community Wishlist Survey:

This proposal received 52 support votes, and was ranked #14 out of 107 proposals.

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz674.
bzimport created this task.Via LegacyOct 10 2004, 6:28 PM
werdna added a comment.Via ConduitNov 1 2006, 1:25 PM
  • Bug 1535 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJul 6 2007, 7:36 AM

ayg wrote:

This should not be a part of core. It's of too narrow use. Would be fine as an extension, though.

werdna added a comment.Via ConduitJul 6 2007, 7:40 AM

Intending to make this as an extension, and have some fairly decent criteria on it. i.e. category members, regex matches, etc.

Mr.Z-man added a comment.Via ConduitSep 16 2008, 1:56 AM
  • Bug 15615 has been marked as a duplicate of this bug. ***
vvv added a comment.Via ConduitSep 27 2008, 2:30 PM

I have semi-working implementation (lacks blocking form) of it for the core.

vvv added a comment.Via ConduitSep 28 2008, 4:09 PM

Fixed in r41352.

bzimport added a comment.Via ConduitSep 28 2008, 7:31 PM

matthew.britton wrote:

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

FunPika added a comment.Via ConduitSep 30 2008, 10:33 AM

Reverted in r41405.

brion added a comment.Via ConduitOct 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:




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.

bzimport added a comment.Via ConduitOct 30 2008, 9:31 PM

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.Via ConduitDec 31 2008, 6:11 PM

Fixed in r45231.

brion added a comment.Via ConduitDec 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.Via ConduitJun 20 2009, 9:59 AM

Created attachment 6242
Proposed patch

Here's revised version of r45231.

Attached: restrictUser.patch

bzimport added a comment.Via ConduitOct 22 2010, 11:02 AM

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?

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

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

bzimport added a comment.Via ConduitAug 24 2011, 2:15 PM

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.Via WebDec 10 2014, 5:24 PM
AS added a subscriber: AS.Via WebJun 18 2015, 10:15 AM
MrStradivarius added a subscriber: MrStradivarius.Via WebJul 19 2015, 4:18 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 TranscriptVia HeraldJul 19 2015, 4:18 AM
Base added a subscriber: Base.Via WebNov 9 2015, 10:41 PM
Scott added a subscriber: Scott.Via WebNov 10 2015, 1:04 AM
waldyrious added a subscriber: waldyrious.Via WebNov 14 2015, 1:58 PM
Man77 removed a subscriber: Man77.Via WebNov 28 2015, 9:49 PM
DannyH set Security to None.
JEumerus added a subscriber: JEumerus.Via WebDec 8 2015, 8:55 PM
DannyH moved this task to Wishlist 11-20 on the Community-Wishlist-Survey workboard.Via WebDec 15 2015, 8:25 PM
Billinghurst added a subscriber: Billinghurst.Via WebDec 17 2015, 4:10 AM

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

Aklapper added a comment.Via Bulk EditThu, Jan 21, 2:54 PM
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 edited the task description. (Show Details)Via WebFri, Feb 5, 11:48 PM

Add Comment