Last modified: 2008-09-28 22:08:58 UTC
When blocking a user or IP address for a long time, admins often protect the user page and/or talk page to prevent further vandalism, and to make sure that templates added there (such as sockpuppet or open proxy templates) are not tampered with. This enhancement would save admins a few steps (navigating to each page and then protecting it).
Created attachment 5320 [details] Proposed patch This should do the trick, just adds two checkboxes which do the same as if the admins had manually protected the pages. Automatically uses the maximum protection available (in a default setup, sysop-only). Only available to those also with the protect permission.
*** This bug has been marked as a duplicate of bug 8440 ***
Per comment by Huji on bug 8440, this isn't a duplicate, as they are slightly different things. Reopening
You could probably check $wgBlockAllowsUTEdit and not show this if that is set to false.
This is also used by admins (at least it was on enwiki when I was there) when indefblocking, mainly for archiving and to stop other users posting there as well. Although if you think that's unnecessary, i'll happily add it in.
(In reply to comment #5) > This is also used by admins (at least it was on enwiki when I was there) when > indefblocking, mainly for archiving and to stop other users posting there as > well. Although if you think that's unnecessary, i'll happily add it in. > Remember that the block form is pretty bloated as is, so helper options should be for things that are fairly common. People can still protect with the tab in other cases.
Created attachment 5337 [details] Proposed patch v2 Fixed patch, only shows if UT editing enabled, and also condensed into one option (to protect both).
Created attachment 5338 [details] Proposed patch v2 (proper version) Uploaded wrong patch
Equivalent behaviour in Bug 8440 implemented, protecting user/usertalk is a rare enough occasion that it doesn't need more bloat onto the block form.
