Last modified: 2011-12-09 08:32:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28816, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26816 - RenameUser should log out target user to prevent unwanted recreation of old username
RenameUser should log out target user to prevent unwanted recreation of old u...
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Renameuser (Other open bugs)
unspecified
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 31863
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-20 16:28 UTC by xenocidic
Modified: 2011-12-09 08:32 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description xenocidic 2011-01-20 16:28:19 UTC
It's fairly common that a user will request a rename usually based on a privacy concern (they used their real name, etc.).

The rename will be performed but because of (I assume) cookies and SUL and such, the account gets recreated automatically - this is usually undesirable.

Rename should perhaps force a userlogout - if possible - to avoid this happening. Or perhaps someone has a more elegant solution.
Comment 1 Antoine "hashar" Musso (WMF) 2011-01-22 13:23:28 UTC
Raised severity enhancement -> normal
Comment 2 Jeff G. 2011-02-16 04:52:36 UTC
Further prevention of automatic re-creation would be helpful.  I wrote the following in bug 17313#C22:
"I suggest creating a way to salt the account names that request successful
renames, implementing it on English Wikipedia, and getting consensus of the
Bureaucrats there to use it."
Comment 3 Aaron Schulz 2011-10-21 19:36:58 UTC
This is already done, but the user_touched change isn't committed till all the job rows are inserted, which could be a quite a few seconds.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links