Last modified: 2013-06-18 16:28:50 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 T17698, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15698 - Change to the special:renameuser functionality
Change to the special:renameuser functionality
Status: RESOLVED DUPLICATE of bug 15212
Product: MediaWiki extensions
Classification: Unclassified
Renameuser (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-23 15:09 UTC by Nicholas
Modified: 2013-06-18 16:28 UTC (History)
3 users (show)

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


Attachments

Description Nicholas 2008-09-23 15:09:38 UTC
Bureaucrats on enwiki go through almost a thousand renames per month. We're thinking of making the Renaming function an integrated feature that is accessible through the "my preferences" tab. The immediate advantage would be preventing non-logged in users from making a request.

On the interface page, this is what I envision:
------------------------------
    New name: [Textbox]
    Reason: [Textbox]
    Automatically recreate old account [checkbox] (to prevent a Grawp-like situation.) (Note: Should be unchecked if renames are done for privacy concerns)
    Place a request (button)
-------------------------------
Mediawiki then checks the following:

   1. Place a warning if restricted characters are present, or if the change is to do with just underscores or first letter caps.
   2. Will the current account be detached from SUL? YES => Warning to user
   3. Is the requested name similar to existing user? == YES => Warning to user (that the request might be denied)
   4. Is requested username available? == NO => Warning to user AND
         1. If requested username not available, does requested username have 0 edits? == Yes => Display usurp instructions. Make the user confirm, and place the request at CHUU
         2. If requested username not available, does requested username have <10 (edit: an arbitrary number) edits to mainspace? YES => place it on CHUU. Clerk or Crat can evaluate the criteria.
   5. If warnings, user needs to confirm a go-ahead.

Finally

   1. Display the request on CHU
   2. Display the block log of user and Display rename history
   3. Places a Google search link. (to check if the username is a commercial enterprise.)



Additional details are available here: http://en.wikipedia.org/wiki/Wikipedia_talk:Changing_username#Change_to_CHU_process
Comment 1 Chad H. 2008-09-23 19:17:17 UTC
If this were implemented, I'd rather not use WP:CHU as the target place for processing requests. Rather, a new specialpage would probably be best. 
Comment 2 Nicholas 2008-12-10 13:29:09 UTC
Agreed. A special page would be the best option. Can the priority of this request be increased? The number of renames is over a 1000 per month, and there are a number of bad requests which unnecessarily consume time.
Comment 3 Siebrand Mazeland 2012-05-22 11:21:55 UTC

*** This bug has been marked as a duplicate of bug 15212 ***

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


Navigation
Links