Last modified: 2011-01-25 00:02:10 UTC
After merging an account, it's impossible to rename a user to the new global username on a project even if the user hasn't logged in with the global username yet to that project. (e.g. global account Bob with accounts on enwiki and frwiki, impossible to rename account Tom to Bob on dewiki.)
That's done on purpose (CentralAuth.php:168-172). The problem is on usurping, so if we move Bob on dewiki to Bob-at-dewiki and want to give that account to Bob25 which is the owner of the global account, there's no way to do that.
This could be worked around by allowing [[m:Special:CentralAuth]] to unmerge a global account entirely. Then we could usurp as required, then remerge. (Unmerging all merged accounts before renaming produces the same error.)
A partial solution would be to allow renaming to a name that for which there is a global account but no local account, provided that the usual SUL merge criteria were met. This seems like a sensible feature to add in general. It wouldn't be a complete fix because it wouldn't help if someone stupidly created a local account *matching* their name that needed to be unmerged.
Maybe add an option to [[m:Special:CentralAuth]] to temporarily disable those checks, so we can usurp as required and re-enable? This would also serve as a general workaround in any case where we need to circumvent the checks.
Why can't users merge accounts that have different names?
Perhaps account A can be renamed to B if B has the same global password and email?
Comment 6 by Aaron Schulz is extremely important. In most cases where people needed to use a different name on certain wiki (perhaps because it was taken by a dormant account), they likely used the very same password and email as in their normal (now global) account. Doing this (allowing renaming where password and email match) would probably solve a large percentage of current problems.
I suggest a solution before global SUL is enabled for all users
Also, people aren't considering the potential of abuse... Once the tool is made open to everybody any disruptive user can register an account on a random tiny wiki strictly to "SUL" an established users username. Say I register "Jimbo Wales" on haw.wikipedia and SUL link it. I would prevent Jimbo Wales from using SUL or the account "Jimbo Wales" on any wiki but the ones he previously registered.
That's irrelevant to the present bug. CC'ing Tim so that he knows the bug number, although I know he knows of the issue.
>>I suggest a solution before global SUL is enabled for all users I think that we must not enable it for all users. Now stewards and bureacrats have many requests. And if we'll enable SUL for other users, stewards and bureaucrats will not sleep many days to make these requests (sorry if my English is bad)
[080327 17:06:46] <Simetrical> brion, has anyone considered the renaming load on bureaucrats when SUL starts kicking in and everyone wants to unify accounts? Maybe sysops should be temporarily given the ability to rename if that starts to become a problem? [080327 17:07:45] <brion> Simetrical: renaming is to be primarily automated and/or user-directed [080327 17:08:03] <brion> bug tim to finish implementing that if you like :) So it shouldn't be an issue for the final rollout.
(In reply to comment #9) > Also, people aren't considering the potential of abuse... Once the tool is made > open to everybody any disruptive user can register an account on a random tiny > wiki strictly to "SUL" an established users username. > > Say I register "Jimbo Wales" on haw.wikipedia and SUL link it. I would prevent > Jimbo Wales from using SUL or the account "Jimbo Wales" on any wiki but the > ones he previously registered. > It is supposed to weight your oldness/editcount, so if you registered Jimbo Wales before he creates the global one, you would lose the account instead of gaining the global one.
Vandal account could have been created earlier ;) Right but what if both accounts are legit and both want to use SUL. What I was getting at was the conflicts...
White Cat, please read the existing documentation rather than speculating on an unrelated bug report. This bug report exists so that we can prioritize and discuss actual relevant code fixes for the actual relevant issue.
*bump* Is there any progression on this bug?
When it's fixed, it will be marked FIXED and all subscribers to the bug will be notified. There's no need to "bump" bugs, especially after just two weeks, or otherwise to post anything that does not directly further the goal of fixing the bug. You just succeed in spamming dozens of people's inboxes for no reason.
It's sorta fixed now, since stewards can delete global account (break SUL link).
Marking as fixed per Comment #18
It should do some email/password validation or something. Deleting accounts is a hack.
Fixed in r35997.
Note I've temporarily reverted r35997 and its predecessor edit for further review (they removed a lot of basic admin functionality and make schema changes).
Is this bug explaining why my secondary account on En.WP could not be unified with all the others? I explain: * My accounts on WMF projects (wikipedia, wiktionary, MEta, Commons, ...) has always been "verdy_p" (with lowercase p). My first acount was created on FR.WP. * Unfortunately in 2004 an account creation in EN.WP got garbled soon after I had created and I could not recover any access to it (the password was apparently incorrectly set before I could register my email address on it, so this account was permantently inacessible. At this time, no admin could rename this account. * For this reason I had to create an alternate account "Verdy_P" (with capital P) that I have used since then ONLY in English Wikipedia and nowhere else (this account has not been processed by SUL, but has tons of edits that I would like to keep in my history) * SUL has just unified all my accounts except the on on En.WP. * I had asked to a EN.WP admin to rename the old broken account "verdy_p" account to "verdy_p2004" so that I can usurpate it by renamig "Verdy_P" (capital P) to "verdy_p" (lowercase p) like on every other wikis. The admin performed just the first step (renamed "verdy_p" to "verdy_p2004") but forgot then to usurpate it by renaming "Verdy_P" (capital P) to "verdy_p" (lowercase p). * Since then, I've seen that SUL has automatically recreated a new account "verdy_p" (lowercase p) with an empty history on English Wikipedia. * I can no longer connect easily between En.WP and other wikis with SUL: I need now to disconnect each time I go to En.WP and then reconnect using "Verdy_P" (same registered email address, same password...), and redisconnect and reconnect before boing back to my home wiki. This is really creating havoc in my history, and this is a situation that is even worse than before SUL, because now SUL is multiplying the niumber of incorrect accounts during my navigation. It's very easy to forget to disconnect and reconnect (something that I did not have to do before SUL, because eachwiki had its own account and cookies without assuming anything from the other wiki). SUL would be great if it effectively tracked the correct accounts used on various wikis, and was NOT creating new accounts automatically when navigating. The way it works is that it always attempts to usurpate another homonymous account when browsing from one wiki to another (it's easy for it to create new accounts: you just have to post something in a discussion...) How an my situation be recovered? I have asked several times to an EN.WP admon to do the job, but I receive no reply. Apparently my request can't be performed, but I have no explained reason why my requests have not been satisfied.
Anyway the system now in place is probably ill-designed: it should not attempt to usurpate identities on all wikis systematically: one should be able to list exception for some wikis by saying that some wiki in the list managed by SUL should use another username: just select the wiki, and indicate the username, and optionally give the password if different. Then it will calidate this triplet (wiki, username, password) and if it matches it will add it to the list (there can be only one account for the same wiki in the list of triplets). If the password is validated and does not match the one used in the current wiki, then the user can be asked to reset his password to a common one for all the listed wikis (this can be part of a further step in the user preferences screen. This way: no more usurpation needed, and no need to rename accounts, and the discussions in histories can keep their existing usernames without linking to another unrelated account that has been usurped only to satisfy SUL. With such option, I could finally merge my "Verdy_P" (capital P) account on EN.WP with the "verdy_p" (lowercase p) accounts used everywhere else.
You could do with being a lot more concise. (In reply to comment #23) > Is this bug explaining why my secondary account on En.WP could not be unified > with all the others? Yes. Your account must be de-unified by a steward. *Then* any conflicting accounts need to be merged, *then* your enwiki account needs to be moved to the correct name, and then you can reunify. > SUL would be great if it effectively tracked the correct accounts used on > various wikis, and was NOT creating new accounts automatically when navigating. That defeats half the point of a unified login. Registering on one wiki needs to equate to registering on all; logging in on one needs to log you in on all. (In reply to comment #24) > Anyway the system now in place is probably ill-designed: it should not attempt > to usurpate identities on all wikis systematically: one should be able to list > exception for some wikis by saying that some wiki in the list managed by SUL > should use another username Possibly, yes (especially nice for wikis using different writing systems). That's an unrelated request and should not be discussed here.
Another concise comment: SUL has automatically recreated another account for me on en.wp, despite I had asked it to be removed (and it has effectively been removed by renaming it: this account was not validated anyway and completely inacessible by anyone as it was bogous). But SUL should not have recreated automatically any account on en.wp because I already had another account that was validated there. Now I have two accounts on en.wp but what is worse is that they are now both *validated*. Why doesn't SUL check first if there's already an existing valdated account with the same email and password before recreating acconts automatically? Really, SUL should NOT automatically create accounts without consent: if one is connecting to a new wiki, there should still exist the possibility to continue with the anonymous status (and keep this information in the session cookie): SUL would only ask the user if he attempts to use an edit action, but not for simple visits). But I am still waiting for you to implement a way to specifiy to SUL that I don't want it to use the default user name. Otherwise SUL will have no use for many users that will complain about their mutually conflicting accounts ans the loss of their past histories... Many users will want to maintain the usernames they have used since ever, and will want to go to newer wikis where their user names is already taken by someone else. SUL is then very disappointing... What we need is just a single signon and a single password with a single email for validation, but not necessarily the same user names...
Anyway the "solution" addopted for allowing merging accounts is certainly the worst: * you loose the user attributions in discussions * past contributions and signatures no longer point to the correct user * it defeats the attributions for copyright, for example in Commons where the renamed user would have signed its contributions in the Author field. * it requires lots of complicate maintenance tasks for checking the status. * it has caused me to loose my past history and being unable to vote in the last Board elections despite of thousands of contributions since 2004 at least Really abandon the idea of renaming accounts: there's no good reason for doing that as a systematic option for solving conflicts. All this compromizes the whole projects when you don't know who has made what somewhere. OK, SUL can be helpful to simplify the creation of new accounts on new wikis, but for old users, this system really "sinks" if users are loosing their accounts, just because one has been inactive for some time. So really: add the possibility to merge accounts with different user names, and please verify that a user already has a validated account (with the same email address) and use this account instead of creating new ones... If you find several accounts, don't choose: allow the user to indicate that SUL should not be used on that wiki, so that the user can continue to logon on it separately (like before SUL), and stay connected there independantly of the connection on other wikis under SUL.
This is the wrong place for objecting to the way it was decided several years ago that SUL would be implemented. I suggest you post to wikitech-l, and maybe foundation-l if you like. This bug is for productive technical discussion on allowing accounts to be renamed to global usernames; please use it for that and that alone.
"This bug is for productive technical discussion on allowing accounts to be renamed to global usernames". I'm exactly on this topic. That's exactly on topic. Renaming past accounts is the wrong solution for the single signon objective, when it breaks all the histories and even the copyright statements in contributions, when the only available information to readers is quite often only the Wiki username. If you allow those names to be renamed, then you should have to delete all past contributions from the old account or effectively not only reanme the accounts but also all the discussions and links present everywhere to the user's page name. I maintain that SUL has created havoc and now it has created an account that I did not want and blocked me from accessing my regular engloish wikipedia account, *because* an account was renamed and then SUL automatically created a new "validated" one that I did not even want. "This is the wrong place for objecting to the way it was decided several years ago that SUL would be implemented." FALSE! This was not decided several years ago, it was just one of several tested solutions by a few contributors, and not enough tests were done to experiment the problems and get reports from users, it got directly released and even the wiki stewards don't care about the problem. So Wikipedia projects are now abusing users rights.
(In reply to comment #29) > That's exactly on topic. Renaming past accounts is the wrong solution for the > single signon objective This bug is not about whether renaming accounts *should be a solution* or not. This bug is about the fact that renaming local accounts to names taken by global users *is not currently possible* without de-unifying the account first. Even if it were not the solution, this functionality should still be made available for the convenience of users who do want it. I'm not going to respond any more until you take this to the correct place (and it seems unlikely that anyone else will either).
Premise: Global accounts are intended for reserving usernames. If you allow any bureucrat (there're quite many) to rename you to a reserved username, you're making a back door for including accounts into the 'protected zone'. You could restrict it so only stewards can rename you. But stewards won't be able to decide if you should be renamed on a local project. Please explain the way to fix that. Perhaps adding a switch to the global account to have it protected/unprotected?
I don't see what abuse scenario you're envisioning with bureaucrats renaming something to your global username. The account will be merged into your global account, so you'll be the one who controls the account.
If at a given time you have all the accounts, you're supposed to be the only one with that name. Having unmerged accounts would be a bug AFAI understand the current system. The problem is that if the renamed account is not yours, there's an unmegerd account with your name. Or are you proposing that when renaming the password gets reset to the global account one?
Yes, the move would integrate the local account into the global one. Of course this should only be possible when the password/e-mail of the local account match those of the global account. See comment #3: > A partial solution would be to allow renaming to a name that for which there is > a global account but no local account, provided that the usual SUL merge > criteria were met. This seems like a sensible feature to add in general. It > wouldn't be a complete fix because it wouldn't help if someone stupidly created > a local account *matching* their name that needed to be unmerged. The part about it not being a complete fix is irrelevant now that accounts can be unmerged; this would be a complete fix for the problem.
Fixed in r37422.
Does this require the global account to have 0 edits? If both the global account and local one have edits can they still be merged?
*** Bug 14721 has been marked as a duplicate of this bug. ***
Yse. I move go to soon renamed to a global username.
