Special:RenameUser should allow suppression of automatically-created redirects
Closed, ResolvedPublic

Description

During a usurp request, renaming the usurped user creates a redirect to User talk:Usurpee (usurped) which typically prevents the usurper's talk page being moved there unless it is first deleted.

A checkbox to allow one to suppressredirect would be helpful.


Version: unspecified
Severity: enhancement

bzimport set Reference to bz23819.
Xeno created this task.Via LegacyJun 7 2010, 1:34 PM
lcawte added a comment.Via ConduitJun 30 2010, 5:16 PM

Hm, I might have a look at this.. It sounds like a good idea.

Xeno added a comment.Via ConduitSep 23 2010, 1:03 PM

Still hoping to see this feature created.

As it stands now, I manually move the pages ahead of the rename; it would be nice to get it all wrapped up into one.

bzimport added a comment.Via ConduitOct 8 2010, 1:01 PM

soxred93 wrote:

r74510

Xeno added a comment.Via ConduitFeb 7 2011, 8:09 PM

I've just tried testing this functionality at the prototype/release-en wiki and was given the following error:

Invalid input

Backtrace:

#0 /srv/org/wikimedia/prototype/wikis/rc/extensions/CentralAuth/CentralAuthUser.php(861): CentralAuthUser::validateList(Array)
#1 /srv/org/wikimedia/prototype/wikis/rc/extensions/CentralAuth/CentralAuthHooks.php(351): CentralAuthUser->adminUnattach(Array)
#2 [internal function]: CentralAuthHooks::onRenameUserPreRename('45', 'About to be ren...', 'Renamed user')
#3 /srv/org/wikimedia/prototype/wikis/rc/includes/Hooks.php(158): call_user_func_array(Array, Array)
#4 /srv/org/wikimedia/prototype/wikis/rc/extensions/Renameuser/Renameuser_body.php(430): wfRunHooks('RenameUserPreRe...', Array)
#5 /srv/org/wikimedia/prototype/wikis/rc/extensions/Renameuser/Renameuser_body.php(275): RenameuserSQL->rename()
#6 /srv/org/wikimedia/prototype/wikis/rc/includes/SpecialPage.php(579): SpecialRenameuser->execute(NULL)
#7 /srv/org/wikimedia/prototype/wikis/rc/includes/Wiki.php(250): SpecialPage::executePath(Object(Title))
#8 /srv/org/wikimedia/prototype/wikis/rc/includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#9 /srv/org/wikimedia/prototype/wikis/rc/index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#10 {main}

Not sure if this is a problem with the code itself, or something to do with the configuration of the wiki. Figured I'd better leave a note here in case.

I note that a user was renamed on Feb 3 seemingly without issue. Meanwhile today, I wasn't able to get the rename to get through even unchecking the different options.

Reedy added a comment.Via ConduitFeb 7 2011, 8:10 PM

CentralAuth isn't properly enabled on the wiki, so we get stupid errors like this...

Xeno added a comment.Via ConduitFeb 8 2011, 11:02 PM

Ok, I have a real one now. We want to be able to pass a "suppressRedirect=1" to have the new box automatically ticked during usurp requests. Amalthea explained to me this this is not possible because of lines 49 to to 60 of r81598.

---Amalthea wrote the following---
If nothing given for these flags, assume they are checked
unless this is a POST submission.
$move_checked = true;
$suppress_checked = false;
if ( $wgRequest->wasPosted() ) {

if ( !$wgRequest->getCheck( 'movepages' ) ) {
  $move_checked = false;
}
if ( $wgRequest->getCheck( 'suppressredirect' ) ) {
  $suppress_checked = true;
}

}

It disregards any values for the options "movepages" and "suppressredirect" if they are passed in via url parameters. Why I don't know, they don't seem sensitive enough for that to me. The check was introduced by "Greg" in revision 20843 when he made the movepages checkbox remember its status after a form submit. When suppressredirect was added, the code for movepages was apparently simply copy&pasted (as you can see the comment is still wrong), and inherited that logic. In my opinion, that "wasPosted" check can be removed entirely here.

ends

Thanks for your swift attention to this.

Reedy added a comment.Via ConduitFeb 25 2011, 5:29 PM

r82804

bzimport added a comment.Via ConduitFeb 26 2011, 9:01 PM

Amalthea.wikimedia wrote:

Eh, I see now, having a checkbox default to 'true' isn't as straightforward.
r82804 consequently changes the default value of 'movepages' to 'false'.
Replacing

$move_checked = $wgRequest->getCheck( 'movepages' );

by

$move_checked = $wgRequest->getBool( 'movepages', !$wgRequest->wasPosted());

should be a good solution: defaults to true, and still allows to set either state via url parameter.

Reedy added a comment.Via ConduitMar 1 2011, 7:03 PM

r83034

Add Comment