Last modified: 2014-11-18 18:07:24 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 8440 - Allow preventing blocked users from editing their talk pages (case-by-case basis when $wgBlockAllowsUTEdit = true)
Allow preventing blocked users from editing their talk pages (case-by-case ba...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
: 10635 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-30 20:16 UTC by Martin Peeks
Modified: 2014-11-18 18:07 UTC (History)
9 users (show)

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


Attachments
patch for adding the "block talk page" option to SpecialBlockip (7.28 KB, patch)
2007-12-19 02:49 UTC, Ryan Schmidt
Details
My proposed patch (4.42 KB, patch)
2008-09-12 05:54 UTC, Matt Johnston
Details

Description Martin Peeks 2006-12-30 20:16:33 UTC
Would it be possible to remove the "autoconfirmed" priveleges from a user
(non-admin) upon blocking, for the duration of that block?  The reason being
that sometimes, even on a short block, a blockee will abuse their right to edit
their own talk page (with {{unblock}} on en-wikipedia), leading to a need for
full protection of the page.  This can be especially damaging on a short block,
when other users may be engaged in dialog with the blocked one, and would be
unable to leave their messages.  Similarly, if the blocking (and/or protecting)
admin of the user (and/or page) forgot to leave a note to the effect of the
situation (blocking and protection, perhaps using a template), it's impossible
for a more helpful editor to add such a template without asking an admin for
help (which takes up extra time).

The removal of the "autoconfirmed" privelege for the duration of the block will
mean that the page only needs semi-protection (which can later be ugraded if
trolling ensues), and when the user returns, they can immediately start editing
and/or archiving their talk page, rather than having to bring the matter to an
administrator's attention and wait for them to resolve the issue, which could be
a long wait on smaller wikis with fewer admins.
Comment 1 Rob Church 2006-12-30 20:19:02 UTC
It seems to me that the justification for this is unsound; it completely negates
the point of being able to allow blocked users to edit their own talk pages in
the first place. In addition, it would break the semantics of the permission -
an autoconfirmed user is autoconfirmed, whether or not s/he is blocked.
Comment 2 Martin Peeks 2006-12-30 20:49:22 UTC
(In reply to comment #1)
> It seems to me that the justification for this is unsound; it completely negates
> the point of being able to allow blocked users to edit their own talk pages in
> the first place. In addition, it would break the semantics of the permission -
> an autoconfirmed user is autoconfirmed, whether or not s/he is blocked.

Well, on many wikis, it's common practice to protect the talk pages of blocked
users if they make themselves a nuisance whilst blocked.  The justification for
my proposal is that it will make it a lot easier for a user to return to normal
behavoir after a block where their talk page has been semi-protected, and by
allowing the continuation of most communication will present as little
disruption to the community as possible.
Comment 3 Rob Church 2006-12-30 20:54:34 UTC
Yes, but in that case, what's the harm in using full protection? It's highly
unlikely that any user who is not autoconfirmed will actually add anything
productive to the discussion.
Comment 4 Martin Peeks 2006-12-30 21:15:03 UTC
Well, the full protection, in my view, causes unnecessary distruption to the
wiki process, especially if, for example, a highly prolific editor has recieved
a short (one week) block for repeated 3RR violations (on wikipedia), and has
protested very vocally at the block, leading to full protection on his talk
page.  What are the problems with this action?

1) No autoconfirmed user would be able to contact the blocked user, and their
proposed message could eventually be lost (which, I suppose, could have a
detrimental effect on Wikipedia (or the wiki in quetion) as a whole (though
that's a long shot :)))

2)When the block on the user expires, it could be some time until they can
actually edit their talk page again, which could delay their return to editing

3)Full protection is generally only (supposed to be) used in exceptional
circumstances.  By being able to limit to semi-protection would prevent overall
disruption, and in some cases allow autoconfirmed users to add to the localised
discussion, where one exists.

Of course, I have no idea about how much extra load this would place on the
servers, or if it's even readily do-able :)
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-30 23:25:06 UTC
Couldn't this request be simplified to "allow an option to block users from
editing their own talk pages"?  It seems you're trying to drive in a nail with a
screwdriver.
Comment 6 Martin Peeks 2006-12-30 23:34:28 UTC
Probably, and probably, respectivally.  I don't know whether that would be
easier to do -if we could have such a system of preventing edits as part of the
blocking interface, we could more easily enforce bans and reblock if the
restriction is needed.  However, this poses the problem of some admins perhaps
removing the user's right to appeal from the offset, which would probably mean
that it would be best not in the blocking interface - but where?  How about a
level in the protection page which appears in the User_talk: namespace, which
can allow the prevention of editing of it by blocked users - that way we get an
extra step in the process, and less likelihood that admins will abuse their powers.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-30 23:37:53 UTC
If admins routinely silence people when they block them without good reason,
they can be disciplined within the wiki.  That's why we have logs.
Comment 8 Martin Peeks 2006-12-30 23:54:35 UTC
True - it would make more sense in the blocking page, and hopefully admins who
use such a tactic could be noticed, though I'm concerned about how easily people
could patrol the logs.  I suppose it's fair to assume that as the admins have
been entrusted with the buttons, they can be entruested with an extra checkbox.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-19 00:01:53 UTC
*** Bug 10635 has been marked as a duplicate of this bug. ***
Comment 10 Mario Hoerich 2007-07-25 13:11:19 UTC
There are two additional, de-centric points to note here (which led to #10635):

* permission for blocked users to edit their talk page has only recently been activated on de and is actually considered a bug by quite a couple of admins, afaict including most RC-admins. Personally, I haven't seen much benefit this far, except to coax users into further violating policies, subsequently leading to longer blocks. Great (ab-)use, really. Anyway, while this is no doubt a social issue and maybe transitional only, it nonetheless creates problems aplenty, which could easily be lessened with a silence-option.

* de is plagued by literally thousands of vandal-accounts, created in a bot-like manner. The vandal's usual M.O. is to create accounts in sixpacks and--if not blocked by then--deface user pages or their talk pages with obscene insults often directed towards specific users. He frequently chooses new users as prey. I'd guestimate a mean value of 50 accounts per day, but that's in no way scientific and could be off by quite a bit. The need to block this vandals' talk pages as well is however just downright annoying and plain superfluous, this is precisely what block options are good for.

A long posts' short conclusion: de needs a "silence"-option. (Or a redeactivation of whichever option gave blocked users permission to write to their talk pages in the first place; which would certainly be _my_ choice.) 
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-25 18:21:17 UTC
The latter can be done, it's a per-wiki option.  Get community consensus and open a bug requesting that blocked users not be allowed to edit their talk pages.  As for the per-block option, for now you just need to take an extra minute to protect the talk page of the user.
Comment 12 Ryan Schmidt 2007-12-19 02:49:30 UTC
Created attachment 4451 [details]
patch for adding the "block talk page" option to SpecialBlockip

Patch adds following features:
* Checkbox for "prevent user from editing own talk page" if $wgBlockAllowsUTEdit = true;
* Prevents showing/setting the checkbox if $wgBlockAllowsUTEdit isn't true
* Fixes the tab index order of [[Special:Blockip]]

Now if a block is performed with this option checked, users cannot edit their own talk page. This patch has been tested extensively and works on the latest (as of this writing) trunk of 1.12. However, it requires a field to be added to the database (use the following SQL query to do so)

ALTER TABLE `ipblocks` ADD `ipb_block_talk` TINYINT( 1 ) NOT NULL DEFAULT '0' AFTER `ipb_deleted` ;
Comment 13 Daniel Cannon (AmiDaniel) 2007-12-19 03:10:11 UTC
Patch works correctly as specified, although it does not modify updaters.

I do, however, have to say, that this seems like a rather useless feature to me. If a user is abusing his talk page post-block, protect his talk page (it would require the same amount of effort to do this as reblocking the user, and I don't really see much benefit in allowing other non-sysops to comment on a blocked user's talk page who can't himself comment there). If a wiki decides it doesn't want users to be able to edit their talk pages, disable $wgBlockAllowsUTEdit. I also worry that this feature could be upsetting on many wikis -- I imagine that many admins will begin selecting the option by default, leaving blocked users with no (or fewer) means through which to appeal the block, and this practice would certainly be frowned upon on many wikis, such as enwiki.

Recommend WONTFIX.
Comment 14 Ryan Schmidt 2007-12-19 03:57:32 UTC
(In reply to comment #13)
> Patch works correctly as specified, although it does not modify updaters.
> 

sorry, didn't know I needed to :(

> I do, however, have to say, that this seems like a rather useless feature to
> me. If a user is abusing his talk page post-block, protect his talk page (it
> would require the same amount of effort to do this as reblocking the user, and
> I don't really see much benefit in allowing other non-sysops to comment on a
> blocked user's talk page who can't himself comment there). If a wiki decides it
> doesn't want users to be able to edit their talk pages, disable
> $wgBlockAllowsUTEdit.

This was meant to be a case-by-case basis of effectively preventing ''only'' the blocked user from editing their own talk page if $wgBlockAllowsUTEdit is enabled. Protecting the page would prevent other users from leaving messages on the blocked user's talk page (since blocked users don't lose autoconfirmed, the talk page would have to be fully protected). As for the benefits of that, I cannot think of any myself, but it may be a nice feature to have on other wikis (remember, Wikimedia Foundation wikis are ''not'' the only sites running MediaWiki, I'm sure at least one wishes to have this feature or else this bug wouldn't exist to begin with). Also, let's count actions required to do it this way vs. protecting:

Checkbox:
1. block user with option checked, no other actions needed once block expires

-OR-

1. block user without setting option, you later realize that they should be blocked from editing talk page
2. unblock user
3. reblock user with option checked

Protecting:
1. block user
2. protect talk page
3. unprotect talk page once block expires

As you can see, the protection method requires either three times more work than if you set the option initially (like when banning confirmed sock accounts created to evade an initial block or when banning accounts that automate edits), or the same amount of actions if you later decide to go add it (plus, you can then change the expiry time of the block depending on how the user behaved, which may be considered as another bonus). However, the time frame of the protection method is ''always'' longer than that of blocking, as it requires you to follow up after the block expires to unprotect the talk page.

> I also worry that this feature could be upsetting on many
> wikis -- I imagine that many admins will begin selecting the option by default,
> leaving blocked users with no (or fewer) means through which to appeal the
> block, and this practice would certainly be frowned upon on many wikis, such as
> enwiki.
> 

If sysops are trusted enough to use sensibility with deletion, protection, and normal blocking, then I don't think that it's much of a problem allowing them to use another tool. If they can't handle that tool, then can they really handle all of the other things as well? Most sysops I've encountered on various wikis generally only use the restrictive features only when they are necessary, opting for the bare minimum of what would work instead. This would just give them extra options for situations brought up in comment #10, where it is obvious that the user is abusing account creation to evade blocks.

> Recommend WONTFIX
>

You just said that the patch fulfills the purpose set out by the bug (except for the updaters modifications), what harm would come out of implementing it if it is used sensibly? While I do agree that the checkbox only fills a niche amount of cases, it is a useful feature nonetheless.
Comment 15 Huji 2008-01-01 12:55:50 UTC
I don't agree this is a useful feature. When an admin is blocking a user, how can he know (forsee) that the user will abuse his talk page? If it turns out that the user is abusing his talk page, which is the better solution: To unblock and reblock with that option checked, or to protect the talk page?

The only situation where such a feature may be useful is when an admin is blocking a user for a second+ time (or a second account of a known vandal), and knows for certain that this person has had a history of abusing talk pages. I think this is a really rare event, and doesn't justify adding such a feature.
Comment 16 Brion Vibber 2008-01-03 22:31:16 UTC
There are some  distinct advantages to having this block option available:

1) Unlike page protection, it expires with the rest of the block. (You could set the expiry time on a page protection manually, but it would be a pain in the butt to get it right.)

2) It can be set at block time if known to be necessary, or modified along with other block options (assuming we get a 'modify block' system done some day). That's convenient for setting.

3) It'll be visible in the block log.

One possible disadvantage is that it might not be clear on the talk page that the blocked user cannot respond. That could be addressed with a little notice text if desired.
Comment 17 Matt Johnston 2008-09-12 05:53:10 UTC
*** Bug 15565 has been marked as a duplicate of this bug. ***
Comment 18 Matt Johnston 2008-09-12 05:54:56 UTC
Created attachment 5321 [details]
My proposed patch

This patch will allow protecting the user and talk pages (different checkboxes), and makes them expire at the exact same time as the block. Will also add to protection log etc exactly as an admin normally achieves this.
Comment 19 Huji 2008-09-12 09:27:44 UTC
Comment on attachment 5321 [details]
My proposed patch

Sorry but you are not taking the correct approach here. If the user talk page is protected, nobody can edit it (except for Administrators), while what we seek here is just to prevent "the user" to edit his own user talk page.
Comment 20 Matt Johnston 2008-09-12 09:35:29 UTC
I see your point, and bug 15565 is best kept as a seperate bug, as they ask for different things. 15565 reopened.
Comment 21 Matt Johnston 2008-09-25 11:45:49 UTC
Done in r41248
Comment 22 Emufarmers 2008-09-30 11:57:11 UTC
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=241967103#Allow_this_user_to_edit_own_talk_page_while_blocked

It seems that this requires more attention.

Unless the implementation of this changes, the release notes should indicate near the top that a query might be necessary to prevent a regression.
Comment 23 Matt Johnston 2008-09-30 12:00:21 UTC
The appropriate changes were already made in r41403 - previous wikis patched will need a query run. I'll add a shell tag here, for doing it on Wikimedia, athough a new bug is probably better.

For reference, it needs an "UPDATE ipblocks SET ipb_allow_usertalk = 1;"
Comment 24 Matt Johnston 2008-10-02 10:55:27 UTC
Problem should be solved now, defaults changed in SVN and appropriate queries run on Wikimedia.

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


Navigation
Links