SUL finalisation/Renaming requests design

The normal mechanism for supporting renames or usurpations utilizes an arcane process of templates and volunteer time which, according to the author of this document, might not scale easily (if at all).

There are multiple parts to this process, not all of which are visible to end users.

Problems

Non-SUL'd accounts cannot request renames on meta (which is the normal mechanism for doing so) as they may not have an account on meta.
Non-SUL'd accounts may not have email addresses associated with them.
Some users may not receive notification that they will be renamed and the process will happen without their intervention. They must be informed that they have been renamed, and must also be allowed to log in to their former wikis using older credentials (which must then expire).

User Stories

They are very simple:

As a user who is going to be forcibly renamed, I would like to request a new name through a self-serve process on my home wiki and in my own language.
As a user, I do not want to lose access to my account.
As a user, I wish for this process to be as painless as possible.
As a steward, I want to have an easy-to-use, scalable interface from which to handle the Global Rename queue.

Work Phases and Project Scope

The initial scope of this project is focused entirely on the SUL Finalization requirements.

That said, a second iteration of the project could be initiated that will make the rename request system more robust and flexible, usable in the future for all rename and usurption requests, with little effort.

The Rename Request Queue

This is a database table that stores pending and completed requests. It should contain the following fields:

Current/Old Username: The username of the user requesting the rename. This may not be an SUL username.
Requested Username: The new, requested username. This is unique.
Local Wiki: The wiki that the request originates from.
Request Time: A datestamp when the request was filed.
Completion Time: A datestamp when the request was completed.
Status: Pending, Completed, or Rejected
Done By: The name of the Steward who closed the request
Comment: A text comment left by the steward upon closing the request. Optional, but assumed with rejections.
Rationale: A future element, this would be the rationale given by a user for the rename request. Not included in phase 1.

Checking for Username Availability

When checking whether or not a username is available for use, the following system should be followed:

Check the global SUL user's list. If the name is there, then fail.
Check the reserved username list (populated by Special:GlobalRenameRequest). If the username is there (in the "requested username" field) and the status is set to "pending", then fail.

Usernames that have been rejected (are in the "reserved" list but status "rejected") are always available. The "salting" of usernames is not supported at this time.

Special Pages

Note: the names of these special pages may be changed; I'm not married to them at all.

Special:GlobalRenameRequest

A mockup showing the Special:GlobalRenameRequest interface

Form Elements

Requested Username: This is a "smart" field. After data has been entered and the field loses focus (onblur), an AJAX system will start checking to determine if the given username is available. A username's availability is checked against two databases: The existing SUL username list and the

Email and Confirm Email: The form requires an email address to be completed. The reason why we are requiring an email at this point in time is because we do not want users to lose access to their accounts in case something goes wrong and they will be able to reset their passwords normally.

Special:GlobalRenameQueue

A mockup showing the Special:GlobalRenameQueue interface

The data on these screens is only available to Stewards. All other users will receive a "permission denied" message.

Much of the work here is done with modal dialogs. Upon opening ("addressing") a request, the modal should include information about the user requesting the rename. Since these users are not SUL'd, we have to ask the local wiki for information about their rights and edit count. We can restrict this search to the local wiki at this time.

See meta:Template:SRUC and usage at meta:Steward_requests/Username_changes#Requests for examples of information and tools that can be presented to augment the request.

Special:PostLoginRename

This screen is a variation on Special:GlobalRenameRequest. This is the screen that users see who have been renamed without their knowledge.

These users will log in to their home wikis using their old username and password. Once they have logged in, they will be given a notification (very big and bold) that they have been forcibly renamed. They will also be presented with the rename request form in case they wish to ask for a new name.

If they do, the process proceeds as above. If they do not, they can cancel out of it.

TODO: Mockups.

Changes to Special:CreateAccount

Names included in the "reserved names list" must also be checked here for available usernames. Currently, the form only checks against the SUL account list.