Last modified: 2011-05-15 10:03:32 UTC
If you have the hideuser right, a checkbox appears on Special:Block labelled "hide username from edits and lists". Selecting this box and then clicking "block" will delete the user page and user talk page, suppress the deletion archive so that sysops can't see it, hide the username in all edits the user ever made (up to 1000 edits), and remove the username from Special:ListUsers. Reverting the action, by unblocking the user, will not undelete the deleted user pages. An extreme action such as this needs a paragraph of explanatory text, and the software needs to be really sure that the user really wants to do it. There's also the architectural issue: we have a block concept, and we have a backend module in Block.php. This action is implemented in the UI modules, and cries out for refactoring. It pretends to be a block but it won't quite work as one due to the very different backend implementation compared to ordinary blocks. The interface on Special:Block does not well match the hide user task, with several of the options being nonsensical: an error is shown if the user selects a finite expiry, and options such as "block anonymous users only" make no sense. There's a strong argument here for splitting the hide user feature out to a separate special page, with a link from Special:Block. The new special page would block the user with appropriate options (via the established backend in Block.php), and do all the things that need to be done to hide the user. If it does stay on Special:Block, there would need to be a confirmation page specific to the hide user feature, with a warning explaining the action.
No longer deletes userpages
Isn't this then a request to refactor the hideuser feature into it's own special page? The current summary suggests that all you're asking for is to change the label for the checkbox on the block form.
Added a checkbox confirmation step in r85166.
