Allow global renaming of global users
Closed, ResolvedPublic

Description

Author: lar

Description:
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.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39817
https://bugzilla.wikimedia.org/show_bug.cgi?id=47918
https://bugzilla.wikimedia.org/show_bug.cgi?id=53905

bzimport set Reference to bz14862.
bzimport created this task.Via LegacyJul 19 2008, 7:44 PM
bzimport added a comment.Via ConduitJul 19 2008, 7:48 PM

mww113 wrote:

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?

bzimport added a comment.Via ConduitJul 19 2008, 7:51 PM

mww113 wrote:

(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.

bzimport added a comment.Via ConduitJul 19 2008, 7:54 PM

lar wrote:

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)

siebrand added a comment.Via ConduitAug 11 2008, 1:14 PM

Component: RenameUser->CentralAuth.

DerHexer added a comment.Via ConduitAug 18 2008, 4:02 PM
  • Bug 15225 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitOct 17 2008, 2:18 PM

klueklue wrote:

*** Bug 14863 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitNov 6 2008, 3:13 PM

esprit.fugace wrote:

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.

werdna added a comment.Via ConduitMar 3 2009, 2:57 AM

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?

bzimport added a comment.Via ConduitFeb 1 2010, 7:13 AM

sjekjr wrote:

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.

bzimport added a comment.Via ConduitAug 3 2010, 1:58 PM

nw.wikipedia wrote:

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.

werdna added a comment.Via ConduitAug 3 2010, 2:00 PM

It's wanted functionality, but somebody has to implement it.

Platonides added a comment.Via ConduitAug 3 2010, 2:11 PM

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).

SoWhy added a comment.Via ConduitJul 18 2011, 5:31 PM

Any news on this?

ToAruShiroiNeko added a comment.Via ConduitAug 15 2011, 12:04 PM

Why is this marked low? It is the single most wanted thing since the creation of SUL!

siebrand added a comment.Via ConduitAug 15 2011, 12:32 PM

Please do not change the priority without having resources. Feel free to bug bugmeister Mark though.

Kozuch added a comment.Via ConduitDec 30 2011, 3:46 PM

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

He7d3r added a comment.Via ConduitDec 30 2011, 5:27 PM

(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]]

SoWhy added a comment.Via ConduitDec 30 2011, 5:53 PM

(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.

ToAruShiroiNeko added a comment.Via ConduitFeb 18 2012, 2:04 PM

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.

DerHexer added a comment.Via ConduitMar 20 2012, 11:17 PM

Any news so far? Stewards and other users are waiting for this tool for ages.

Eloquence added a comment.Via ConduitAug 30 2012, 8:35 AM

Raising the importance on this and adding RobLa; as far as CentralAuth issues go, this is one of the more significant ones remaining.

RobLa-WMF added a comment.Via ConduitAug 30 2012, 7:21 PM

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.

MZMcBride added a comment.Via ConduitSep 4 2012, 4:44 AM

(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.

MZMcBride added a comment.Via ConduitSep 4 2012, 4:47 AM

(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.

csteipp added a comment.Via ConduitDec 17 2012, 6:27 PM

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.
Krenair added a comment.Via ConduitDec 17 2012, 6:36 PM

I'm going to have a go at this.

Trijnstel added a comment.Via ConduitDec 17 2012, 9:54 PM

(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.

hoo added a comment.Via ConduitDec 17 2012, 9:57 PM

(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.

Jyothis added a comment.Via ConduitDec 18 2012, 12:44 AM

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.

Krenair added a comment.Via ConduitDec 18 2012, 1:12 AM

Work in progress at Gerrit change 39171

Scott added a comment.Via ConduitFeb 17 2013, 3:59 PM

(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

Jdforrester-WMF added a comment.Via ConduitFeb 17 2013, 8:04 PM

(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.

Nemo_bis added a comment.Via ConduitFeb 17 2013, 9:53 PM

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).

Nemo_bis added a comment.Via ConduitApr 30 2013, 11:37 PM

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?

Jdforrester-WMF added a comment.Via ConduitMay 1 2013, 3:19 AM

(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.

Nemo_bis added a comment.Via ConduitMay 1 2013, 7:56 AM

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.

Aklapper added a comment.Via ConduitSep 26 2013, 2:31 PM

[Assignee was removed, hence also resetting ASSIGNED status]

gerritbot added a comment.Via ConduitOct 29 2013, 12:36 AM

Change 92468 had a related patch set uploaded by Legoktm:
[WIP] Allow for global renaming of users

https://gerrit.wikimedia.org/r/92468

Matanya added a comment.Via ConduitJun 15 2014, 9:36 AM

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.

Nemo_bis added a comment.Via ConduitJun 15 2014, 11:08 AM

(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.

Deskana added a comment.Via ConduitJun 17 2014, 12:56 AM

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

gerritbot added a comment.Via ConduitJul 3 2014, 5:30 PM

Change 92468 merged by jenkins-bot:
Allow for global renaming of users

https://gerrit.wikimedia.org/r/92468

Legoktm added a comment.Via ConduitJul 3 2014, 5:59 PM

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.

Legoktm added a comment.Via ConduitJul 9 2014, 11:48 PM

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!

Kozuch awarded a token.Via WebDec 17 2014, 8:02 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.