majorly.wiki wrote:

What if the account had literally just registered, quite recently? That doesn't sound very fair.

Well it is a pretty unlikely race condition that an account would have just been created, but never used, at the same time that someone else wants to unify a global account with the same name. But if you really want to worry about that one could add a check that the unused account was at least X weeks old, for some reasonable value of X.

I believe this was a temporary hack to avoid potential security issues with the email being set differently (leading to the possibility that the creator of the no-edits account could then take over the global account). This is probably obsolete now, with the global e-mail setting overriding the old local one, and can be removed

WJBscribe wrote:

It would save a lot of bureaucrat time if this happened automatically. Alternatively, I am thinking of trying to get enwiki to approve a bot with bureaucrat rights to automatically rename out of the way every account with zero edits and the same name as a global account, as those attached to the global account won't be able to be renamed. It would seem simpler however if the software just gave away accounts without edits automatically, and I wanted to explore that possibility before going down the (no doubt arduous) route of getting a bot approved for this task.

wantman wrote:

I have a very common username (Sam). There are over 60 projects that have users with accounts that are not me. All but a handful have no edits, and most are several years old. It would take me forever to try and usurp all these accounts. SUL has had the effect of discouraging me from leaving messages on projects I haven't been to before. For example, I thought of leaving a comment on French Wikipedia. I found that someone had my name, but there are no contributions and there is no log. I have the option of trying to figure out how to usurp the account and then remerge my accounts or editing anonymously or editing with a different user name and later renaming and usurping the account. None of these options are worth the time and effort involved, so I didn't leave the comment. After these old, zero contribution accounts automatically get usurped, I'll spend the time to usurp the handful that remain. Until then, I just don't see the point.

mike.lifeguard+bugs wrote:

Didn't evil_plans.txt have a half-decent method of automatically merging accounts?

There are still issues. Tim notes that malicious preferences and user JS could be used to take over an account.

Would it be sensible to:
Wipe preferences and userspace when taking over an account;
Rename the old user to some new name when taking it over; or
Require user interaction to take over an account?

As far as I know stewards are since long time no longer able to merge global accounts via CentralAuth, and this was only possible on the begginings of SUL. Is this then still an issue? Can it be closed?

I am fairly skeptical about the requested change. The situation for as long as I remember have been (and correct me if that changed) has been that the account usurpation policy is up to each individual project, and some projects never allowed usurpation under any circumstances. I am concerned that we might be possibly circumventing local policies with this decision.

Correct me if I am wrong.

@vvv and @Aklapper I suggest we close the bug. Since SUL finalisation happened, all local account conflicts have been cleared by usurping them to <username>~<localdbname>. Local bureaucrats also lost the ability to rename accounts and all is now centrally handled at Meta. The issues the requester mentions IMHO no longer exist.