Last modified: 2014-09-26 22:42:02 UTC
This enhancement request is related to 13507 but is not the same. The request here is to implement a mechanism in which a trusted user (steward or some global renamer group if one is created) to globally rename a user that has already been unified. The details would need to be worked out, but the idea is that the system would check to see if the target name has been taken on any wikis, and if it has, drop the global association on those wikis (if prompted to do so) or abandon the request (if the prompt was answered negatively)... users would then have to seek local rename on those wikis (perhaps via usurp). (once renamed the behaviour we see now where the newly renamed account can be properly associated with the global one (which is awesome) would allow reassociation). We stewards are seeing an increasing number of requests for rename. The current way to do it, I think, requires un SULing, and local renames on every wiki where there is an account, and then re SULing.
I don't like that idea. Stewards have rename rights on all wikis, and it's locally logged. Why log something on meta when it can be logged locally?
(In reply to comment #1) > I don't like that idea. Stewards have rename rights on all wikis, and it's > locally logged. Why log something on meta when it can be logged locally? > Revise my opinion, noticing the long process that stewards have to go through to rename a unified account.
Yes, it's a lot of wasted time and effort on a lot of wikis to rename a user with a lot. If I wanted to rename my current user "Lar" to "Larry Pieniazek" (for example, that account is already SULed by me to prevent impersonation) upwards of 50 different wikis would need to be involved as I have contribs on a lot of wikis. Of course I'm a pathological case. I'm not averse to the suggestion that the local rename log should get an entry as well, for every account affected, as traceability is goodness. (so please consider that part of the request)
Component: RenameUser->CentralAuth.
*** Bug 15225 has been marked as a duplicate of this bug. ***
*** Bug 14863 has been marked as a duplicate of this bug. ***
Given that new accounts are automatically made global, I think this renaming problem may be a little urgent. Last time I renamed a user who didn't know he had a global account. He didn't even notice : he logged in automatically (from cookie or from another wiki, I don't know) under his old user name, and went on contributing for some time before he ask what he had to do to complete the renaming. Now he has two accounts on the same wiki (which I hope he may later merge), and one of them is marked as "automatically created on login" on ALL wikis ( http://toolserver.org/~vvv/sulutil.php?user=MTPICHON+ , the duplicate is http://toolserver.org/~vvv/sulutil.php?user=maith%C3%A938) This sort of mess is going to happen more and more often if local bureaucrats or stewards can't rename global account easily, I think.
Just thinking about the architecture for this. It seems that there are a few alternatives to consider here: 1/ The equivalent of doing a rename on every wiki on which the user is active. This is the "shotgun" approach. 2/ If 1/ is too expensive, add a job queue entry for each wiki on which the user is active on that wiki, which will initialise the user renaming process on each wiki. I'm not certain on how much less expensive than 1/ this is -- IIRC most of the work done for a rename is done by the job queue anyway. Are there other possible solutions to this problem?
This seems like an important small feature. Related fixes: right now when trying to rename a user via the above process one gets a warning during every rename, suggesting this isn't the 'right way' to do a global rename. Instead, the rename interface could simply ask whether this is a one-wiki-only rename or a global rename, and try to carry out the action accordingly.
I just wanted to see if we could possibly get a follow-up on this. If this bug is to be marked as WONTFIX, that would be fine, but it would be nice to know one way or the other.
It's wanted functionality, but somebody has to implement it.
No, this is not a WONTFIX, just a "nobody has done it yet". I think the option 1 is the right one, but the renamer also performs local actions, so it should exist there (not a problem for us).
Any news on this?
Why is this marked low? It is the single most wanted thing since the creation of SUL!
Please do not change the priority without having resources. Feel free to bug bugmeister Mark though.
Because of votes rasing importance/priority according to following scheme: 15+ votes - highest 5-15 votes - high Community must have a voice within development. Regards, Kozuch http://en.wikipedia.org/wiki/User:Kozuch
(In reply to comment #16) > Because of votes rasing importance/priority according to following scheme: As far as I know, the priority should be set according to the following scheme: [[mw:Bug_management/Bugzilla_usage#Priority]]
(In reply to comment #17) > (In reply to comment #16) > > Because of votes rasing importance/priority according to following scheme: > > As far as I know, the priority should be set according to the following scheme: > [[mw:Bug_management/Bugzilla_usage#Priority]] I agree. The community might like to see this implemented (I certainly do) but since the one in charge of bugs decided to use the "priority" variable to help them track the importance of a bug based on the scheme cited in comment #17, we should not change it; wanting something is one thing but it shouldn't screw up the management. As such, I've reset the priority to "low" although I personally hope someone will be able to handle this request soon.
To be honest I do not see the difficulties associated with this. The existing rename function only needs to be looped right? In a past discussion I was told the real difficulty is keeping the account synced on all tables. I would totally be fine to wait a day or two when my account is disabled until the rename is complete. Also perhaps user id and username should be independent of each other.
Any news so far? Stewards and other users are waiting for this tool for ages.
Raising the importance on this and adding RobLa; as far as CentralAuth issues go, this is one of the more significant ones remaining.
Assigning to Chris and adding Jack to the cc. It's not currently in the table on this page: https://www.mediawiki.org/wiki/Admin_tools_development#Roadmap ...but it sounds like it may need to get added to it.
(In reply to comment #22) > Assigning to Chris and adding Jack to the cc. It's not currently in the table > on this page: > https://www.mediawiki.org/wiki/Admin_tools_development#Roadmap > > ...but it sounds like it may need to get added to it. I don't see how this bug is related to admin tools development. The Wikimedia stewards have now suggested streamlining the global rename process from the policy side: <https://meta.wikimedia.org/wiki/Global_rename_policy>.
(In reply to comment #8) > Are there other possible solutions to this problem? Banning user renames or abstracting the database further so that it isn't so God-awful painful to do user renames. Neither of these options is likely to be implemented, though.
Just a few notes on this, in case someone wants to launch in: * There probably needs to be a new global rename permission * The basic functionality is: ** Make sure the target username isn't already a global name in CentralAuth ** Make sure the target username is available on all wikis where the user has attached accounts ** Update globalnames, globaluser, localnames, localuser ** For each attached wiki, add a job to do the rename on the local wiki * The account(s) will probably need to be locked during this whole process, since if the user logs in between the time when the global account is renamed and the local wiki is renamed, bad things will happen.
I'm going to have a go at this.
(In reply to comment #25) > Just a few notes on this, in case someone wants to launch in: > > * There probably needs to be a new global rename permission > * The basic functionality is: > ** Make sure the target username isn't already a global name in CentralAuth > ** Make sure the target username is available on all wikis where the user has > attached accounts > ** Update globalnames, globaluser, localnames, localuser > ** For each attached wiki, add a job to do the rename on the local wiki > * The account(s) will probably need to be locked during this whole process, > since if the user logs in between the time when the global account is renamed > and the local wiki is renamed, bad things will happen. And it might be also useful to give a warning when the username is in use somewhere (no global account, but unattached accounts on some wikis where the user doesn't have to be renamed). Just a suggestion.
(In reply to comment #27) > And it might be also useful to give a warning when the username is in use > somewhere (no global account, but unattached accounts on some wikis where the > user doesn't have to be renamed). Just a suggestion. I don't think we should allow renaming towards names which are already used somewhere at all.
Marius, though many people dont think that is necessary, a good number of requests are to rename to an existing account which is unused or inactive or locked. Usual practice is to leave a note to the the user who is losing the account to see if they have plans to be active or have objection in this rename. we wait for a few weeks and if we dont see a response, we do allow the requestor to take that name.
Work in progress at Gerrit change #39171
(In reply to comment #28) > I don't think we should allow renaming towards names which are already used > somewhere at all. According to Brion, the plan is that eventually all accounts which have a name conflict with an SUL account somewhere else will be forcibly renamed. https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/evil-plans.txt
(In reply to comment #31) > (In reply to comment #28) > > I don't think we should allow renaming towards names which are already used > > somewhere at all. > > According to Brion, the plan is that eventually all accounts which have a > name > conflict with an SUL account somewhere else will be forcibly renamed. > > https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/ > evil-plans.txt That's from 2006 - a more current list of work in this area is in [[mw:Admin tools development/Roadmap]]; in particular, the first bullet of the "other tasks" section.
Also, global renaming is indeed a step towards having less conflicts (well, it should; doing renames which add conflicts would be quite evil), but forceful renames or other restrictions completely forbidding non-globally unique usernames to be used, even in cases where the different users are not disturbing each other at all (different languages etc.), is really evil/hard to do properly/impossible, see https://gerrit.wikimedia.org/r/#/c/16922/ which was -2'ed. In fact I think there's not even a bug for those evil plans (if I'm wrong sorry for going OT).
https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=5428771#Finalization_of_Wikimedia_account_unification_.28SUL.29
Commit message doesn't explain how global account merged are handled, if at all. Imagine A@global (composed of A@commonswiki and A@metawiki both attached), B@global (composed of B@wikidatawiki and B@metawiki both attached), C@global (composed only of C@mediawikiwiki). Which of the following is true? 0) B and C can't be renamed to A. 1) B can't be renamed to A, C can (C@global is deleted, the local account is attached to A@global). 2) C can be renamed to A as above, and also B can (but B@metawiki is left behind, and B@global stays). See also https://meta.wikimedia.org/w/index.php?title=Talk%3ASingle_User_Login_finalisation_announcement&diff=5450081&oldid=5450011 Is this a separate feature request? Will it be done before the final forceful rename day?
(In reply to comment #35) > Commit message doesn't explain how global account merged are handled, if at > all. Because they are not, and this is out of the scope of this bug. [Snip] > Is this a separate feature request? Yes. > Will it be done before the final forceful rename day? It's very unlikely, but if a volunteer wants to write such a tool we'd be glad to review it.
Ah. The forceful renames will be much more catastrophic than I thought then, this tool won't help; I've split the request to bug 47918. Nice to know, thanks.
[Assignee was removed, hence also resetting ASSIGNED status]
Change 92468 had a related patch set uploaded by Legoktm: [WIP] Allow for global renaming of users https://gerrit.wikimedia.org/r/92468
It is very nice this is going to be deployed. It would be even nicer if stewards were notified in advanced, and some feedback was shared.
(In reply to matanya from comment #40) > It is very nice this is going to be deployed. It would be even nicer if > stewards were notified in advanced, and some feedback was shared. Thanks pirsquared for doing that. https://meta.wikimedia.org/w/index.php?diff=8884057&oldid=8882213 Bug 35707 is clearly a volunteer-led project.
Deployment of this has been delayed by two weeks. See this for more info: http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-June/000750.html
Change 92468 merged by jenkins-bot: Allow for global renaming of users https://gerrit.wikimedia.org/r/92468
Code has now been merged into the repository, and has been deployed to beta labs for testing. Please test it there! I'll close this bug once it gets deployed to production.
This was successfully deployed today, and hoo has left a note for the stewards: <https://meta.wikimedia.org/w/index.php?title=Stewards%27_noticeboard&diff=prev&oldid=9144799>. Thanks to everyone who finally made this happen!
