|←Single login||Unified login|
|This is an archived proposal for the implementation of single user login. For more information, see the single login documentation page.|
Thinking the other day, I came up with my own process for migration, that in many ways is similar to tha one at single login, in that it assumes a transition period, rather than attempting a "big bang". However, I was thinking of a more human way of resolving "same username, different people" scenarios, in the hope that this would not be too common occurrence. [After all, the usernames that are first to go in one language, won't be the first to go in another: I shouldn't think many Japanese users will have registered as John_Smith!]
Combining some of my thoughts with some mentioned there, we could proceed as follows:
- Create a list of all users for each wiki (including e-mail addresses, where supplied)
- Reserve all these names in the new DB; we don't want conflicts arising between newly created accounts and accounts waiting to be migrated.
- Auto-migrate all users with globally unique names to the new database
- Create a table of users with names already taken on other projects
- If more than one user with a given name have entered the same e-mail address, mark them as "probably matching"
- Possibly, if all users with a given name use the same address, we can auto-migrate, although that would probably require the passwords to match as well, otherwise we wouldn't know what to choose. If not, they could be asked at logon to confirm that the accounts can be merged, typing the password for each one, and the new password desired. They could then tick a box if they weren't the same person after all, and the next step would come into play.
- If a name looks to be used by multiple people (i.e. there are at least some accounts with no/non-matching e-mail addresses), use a bot to alert those people on their User_talk: pages that they need to sort this out. Alternatively, we could alert them at logon, but basically we want to give them a chance to either:
- confirm that they are actually the same person, holding multiple accounts - this could be done via a Special page where they can enter the passwords for all the synonymous accounts, allowing them to continue editing on a one-project login in the mean-time
- get in touch with the other users with the same name, to decide who should keep it. I think this is better than using a mechanical rule, since various things can be taken into account: old/new, regular/casual, recent/departed, well-known to the community/no real name-recognition built up yet...
This obviously requires some central place where settlements can be brokered for problem usernames, providing: a)interpretters, to make sure that disputing users understand each other properly; and b)a mechanism for manually enacting the transfer of one user to the same-named account, and the other to a new name. This seems over the top in some ways, but I think it will save more problems than it will create; I also think it's more in the Wikimedia spirit.
I see there as being the following cases:
|case||procedure per suggestion above|
|globally unique username||automigration|
|N accounts w/ same name, 1 e-mail address||automigrtion|
|N accounts w/ same name, 1 actual user||manual confirmation by password|
|N accounts w/ same name, X distinct active users||resolution process: discussion|
|N accounts w/ same name, 1 active user, Y ex-users||wait for time-out|
|N accounts w/ same name, X active users, Y ex-users||ack! discuss and wait?|
As you can see, we need some kind of time-out: this is because, if we go down the "resolve by discussion" route, we can't just let one user claim the name because the other one hasn't shown up yet. I guess it may sometimes be obvious that one account is more worth the name than the other; and there's no reason that someone can't leave the name to whoever else has it, and pick a new one. But in more complicated cases, we'd need to set a limit for a user who doesn't reply to requests to respond before they have to pick a new name by default.
Hopefully, a lot of this wouldn't be necessary, because there wouldn't be that many genuinely overlapping usernames. Indeed, the more chances we give people to assist the username resolution process, the less we need to worry about copyright issues, because names that point to the same person will not need clarifying. - IMSoP 19:34, 19 Sep 2004 (UTC)
Technical issues of indefinite transition 
An indefinite transition period is preferable, because it allows users to continue logging in with their old username until their account has been migrated successfully. In fact, any forced name-change will create a problem here: the user will have to be told to try their old password with a new name, or given a specific "migrate disabled account" link.
I think the main technical issue with this approach will be the need to constantly deal with two parallel sets of users everywhere in the software. The software could special-case
if(user_id < $FIRST_SSO) for everything like history listings, so that the info could be looked up in the local database instead of the global one; but that's not nice for software maintainability.
Thinking about it, this can be avoided if the lookup to the user database can "know" what project it is being called from: it can then do the
if(user_id < $FIRST_SSO) check, and return data from either the global user table, or the appropriate local one (which would have been imported from the separate project databases). Similarly, usernames marked as pending (i.e. reserved for existing user(s), but not yet migrated) in the central DB can be re-resolved to the appropriate entry before the function returns.
This way, I don't think we'd need to force migration before editing (although obviously we'd encourage it), or have any kind of "this is a new-style login" box: if the user name was marked as pending, it would put up a reminder, but log in using the old table. Attributions for and references to unresolved duplicate usernames would also remain correct, only needing to be changed and disambiguated when users agreed to give up their old name in favour of a new one. [Note that it won't matter if fr:User:A and en:User:A carry on coexisting forever; they already do!] - IMSoP 19:34, 19 Sep 2004 (UTC)