Last modified: 2014-11-18 18:07:24 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.
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.
(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.
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.
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 :)
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.
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.
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.
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.
*** Bug 10635 has been marked as a duplicate of this bug. ***
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.)
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.
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` ;
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.
(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.
*** Bug 15565 has been marked as a duplicate of this bug. ***
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 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.
I see your point, and bug 15565 is best kept as a seperate bug, as they ask for different things. 15565 reopened.
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.
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;"
Problem should be solved now, defaults changed in SVN and appropriate queries run on Wikimedia.