robchur wrote:

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.

martinp23 wrote:

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

robchur wrote:

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.

martinp23 wrote:

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

ayg wrote:

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.

martinp23 wrote:

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.

ayg wrote:

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.

martinp23 wrote:

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.

ayg wrote:

*** Bug 10635 has been marked as a duplicate of this bug. ***

spambox wrote:

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

ayg wrote:

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.

skizzerz wrote:

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 ;

attachment BlockTalkPages.patch ignored as obsolete

cannon.danielc wrote:

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.

skizzerz wrote:

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

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.

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.

mattj wrote:

*** Bug 15565 has been marked as a duplicate of this bug. ***

mattj wrote:

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.

attachment autoprotectonblock.patch ignored as obsolete

Comment on attachment 5321
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.

mattj wrote:

I see your point, and bug 15565 is best kept as a seperate bug, as they ask for different things. 15565 reopened.

mattj wrote:

Done in r41248

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.

mattj wrote:

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;"

mattj wrote:

Problem should be solved now, defaults changed in SVN and appropriate queries run on Wikimedia.