Last modified: 2014-09-26 18:20:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 674 - Allow users to be blocked from editing a specific article
Allow users to be blocked from editing a specific article
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Normal enhancement with 50 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
: 1535 15615 (view as bug list)
Depends on: 14636
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-10 18:28 UTC by elian
Modified: 2014-09-26 18:20 UTC (History)
23 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed patch (53.87 KB, patch)
2009-06-20 09:59 UTC, Victor Vasiliev
Details

Description elian 2004-10-10 18:28:36 UTC
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.
Comment 2 Andrew Garrett 2006-11-01 13:25:19 UTC
*** Bug 1535 has been marked as a duplicate of this bug. ***
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-06 07:36:20 UTC
This should not be a part of core.  It's of too narrow use.  Would be fine as an extension, though.
Comment 4 Andrew Garrett 2007-07-06 07:40:09 UTC
Intending to make this as an extension, and have some fairly decent criteria on it. i.e. category members, regex matches, etc.
Comment 5 Alex Z. 2008-09-16 01:56:07 UTC
*** Bug 15615 has been marked as a duplicate of this bug. ***
Comment 6 Victor Vasiliev 2008-09-27 14:30:29 UTC
I have semi-working implementation (lacks blocking form) of it for the core.
Comment 7 Victor Vasiliev 2008-09-28 16:09:01 UTC
Fixed in r41352.
Comment 8 Gurch 2008-09-28 19:31:36 UTC
Why is this part of core? I concur with comment #3.
Comment 9 FunPika 2008-09-30 10:33:14 UTC
Reverted in r41405. 
Comment 10 Brion Vibber 2008-10-01 20:13:38 UTC
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.
Comment 11 pgrawehr 2008-10-30 21:31:10 UTC
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. 
Comment 12 Victor Vasiliev 2008-12-31 18:11:54 UTC
Fixed in r45231.
Comment 13 Brion Vibber 2008-12-31 18:56:56 UTC
Reverted for now in r45241

Unexpected schema changes in the middle of code review and run-up to 1.14 freeze
Comment 14 Victor Vasiliev 2009-06-20 09:59:28 UTC
Created attachment 6242 [details]
Proposed patch

Here's revised version of r45231.
Comment 15 M.O.X 2010-10-22 11:02:32 UTC
[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?
Comment 16 p858snake 2011-04-30 00:09:50 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 17 John Du Hart 2011-08-24 14:15:44 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links