Last modified: 2014-11-18 17:40:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 35707 - (sulfinalization) Complete unification of all accounts to SUL
(sulfinalization)
Complete unification of all accounts to SUL
Status: ASSIGNED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Highest enhancement with 5 votes (vote)
: ---
Assigned To: Kunal Mehta (Legoktm)
https://meta.wikimedia.org/wiki/Singl...
: tracking
Depends on: 39817 global-user-merge 67350 68069 71241 14862 54760 54761 61876 67901 67995 68886 68924 68927 69291 70392 70850 71924 72123
Blocks: tracking 16690 49315 66699 22673 49740
  Show dependency treegraph
 
Reported: 2012-04-04 21:39 UTC by Mark A. Hershberger
Modified: 2014-11-18 17:40 UTC (History)
41 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mark A. Hershberger 2012-04-04 21:39:40 UTC
From the (un)-archived discussion at meta (http://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&diff=next&oldid=3619272), [[User:JohnnyMrNinja]] writes (in part):

  I am proposing that account unification be completed for all eligible accounts
  without requiring the user to take any additional steps. This would make UL the
  rule rather than the exception that it currently is, and bring us closer to the
  goals of universal watchlists, recent changes, interwiki page moves, etc. This
  would be especially helpful on Commons, which has so many images that were
  originally uploaded at another WMF wiki, enabling better attribution without
  interwiki links. I propose that it be carried out as a one-time process rather
  than a continuous automatic software process, allowing users to still adjust
  ULs as they see fit.

  [...]what I mean by "eligible accounts" was all accounts without existing
  conflicts, as these can be taken care of by an automated process. Accounts that
  have conflicts would be unaffected by this specific proposal. Conflicts could
  not be solved by any automated process, as each case would be different.

Looks like it has enormous support on meta.  I'm not sure about the ins and outs here, so I'm going to add people who I think know more as well as post this bug to wikitech-l.
Comment 1 Mark A. Hershberger 2012-04-04 21:55:19 UTC
Started a thread for discussion of this on Wikitech-l: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60388
Comment 2 Mark A. Hershberger 2012-04-06 19:07:38 UTC
This bit was broken off of the thread but had important information: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60484
Comment 3 Victor Vasiliev 2012-04-21 21:27:55 UTC
Right now I do not get what specifically that user asks. I am not even sure if he understands what he is talking about. Could you elaborate, please?
Comment 4 Stefan2 2012-04-21 23:41:34 UTC
(In reply to comment #3)
> Right now I do not get what specifically that user asks. I am not even sure if
> he understands what he is talking about. Could you elaborate, please?

In the past, all accounts were local. Users who still have local accounts can go to the page "Special:MergeAccount" at any WMF project whilst logged in to create an SUL account. Some users have not gone to "Special:MergeAccount" (possibly because SUL is unknown to these users). The proposal is to automatically do the "Special:MergeAccount" joining for the remaining users (as long as there are no conflicts).

I don't see why there would be issues with indefinitely locked accounts. Some of them might only have been active on one project (in which case SUL would have no advantage but also no disadvantage as the user probably wouldn't start editing at other projects anyway, and they could just register for a local account if they wanted). Other users might have been active on multiple projects, and in that case SUL would give the advantage that the users could be globally locked.
Comment 5 Victor Vasiliev 2012-04-22 00:09:04 UTC
(In reply to comment #4)
> In the past, all accounts were local. Users who still have local accounts can
> go to the page "Special:MergeAccount" at any WMF project whilst logged in to
> create an SUL account. Some users have not gone to "Special:MergeAccount"
> (possibly because SUL is unknown to these users). The proposal is to
> automatically do the "Special:MergeAccount" joining for the remaining users (as
> long as there are no conflicts).

You cannot really merge accounts automatically, since you do not know whether all those users are the same users in different projects. The reason why we ask for password on Special:MergeAccount is that otherwise we cannot even check if two password hashes are the same, since they are hashed and salted (and each has a different salt).

It is true that you could look for alternative criteria of equivalence like all accounts having the same confirmed email address, or check the password and do an auto-merge on login, or merge all single-wiki accounts, but I personally do not believe that the benefits of such a feature (which are not apparent to me) would outweigh its costs of implementation.
Comment 6 Daniel Friesen 2012-04-22 05:42:55 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > In the past, all accounts were local. Users who still have local accounts can
> > go to the page "Special:MergeAccount" at any WMF project whilst logged in to
> > create an SUL account. Some users have not gone to "Special:MergeAccount"
> > (possibly because SUL is unknown to these users). The proposal is to
> > automatically do the "Special:MergeAccount" joining for the remaining users (as
> > long as there are no conflicts).
> 
> You cannot really merge accounts automatically, since you do not know whether
> all those users are the same users in different projects. The reason why we ask
> for password on Special:MergeAccount is that otherwise we cannot even check if
> two password hashes are the same, since they are hashed and salted (and each
> has a different salt).
> 
> It is true that you could look for alternative criteria of equivalence like all
> accounts having the same confirmed email address, or check the password and do
> an auto-merge on login, or merge all single-wiki accounts, but I personally do
> not believe that the benefits of such a feature (which are not apparent to me)
> would outweigh its costs of implementation.

This bug isn't suggesting that we automatically merge User:A on en.wp and User:A on de.wp automatically. It's suggesting that we automatically make User:A global if there is no User:A on de.wp, etc... Just like we do with new user creation.
Comment 7 Jarry1250 2012-09-03 13:00:16 UTC
Any updates on this one?
Comment 8 Amgine 2013-03-13 05:10:26 UTC
<blinks w00tingly>
Comment 9 James Forrester 2013-05-01 03:22:22 UTC
This doesn't remotely block bug 36939.

Noting that this is assigned to me and actually happening now.
Comment 10 Andre Klapper 2013-08-23 09:33:55 UTC
I've lost track for when this is planned to be done and cannot find dates on https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement or https://meta.wikimedia.org/wiki/Help:Unified_login . Could somebody enlighten me?
Comment 11 Trijnstel 2013-08-23 09:39:53 UTC
(In reply to comment #10)
> I've lost track for when this is planned to be done and cannot find dates on
> https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement
> or
> https://meta.wikimedia.org/wiki/Help:Unified_login . Could somebody enlighten
> me?

I wondered too as I saw this change from "August 2013" to "sometime", so I asked James Forrester this week, but no reply up to now. Would love an answer.
Comment 12 Trijnstel 2013-08-23 09:40:20 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > I've lost track for when this is planned to be done and cannot find dates on
> > https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement
> > or
> > https://meta.wikimedia.org/wiki/Help:Unified_login . Could somebody enlighten
> > me?
> 
> I wondered too as I saw this change from "August 2013" to "sometime", so I
> asked James Forrester this week, but no reply up to now. Would love an
> answer.

https://meta.wikimedia.org/w/index.php?title=Single_User_Login_finalisation_announcement&diff=5726233&oldid=5643305 (sorry, forgot to add the link)
Comment 13 Andre Klapper 2013-08-26 15:32:12 UTC
WMF's Release manager told me that this is postponed to an unknown date, as currently https://meta.wikimedia.org/wiki/HTTPS binds resources.
Comment 14 Nemo 2013-09-04 06:59:44 UTC
(In reply to comment #13)
> WMF's Release manager told me that this is postponed to an unknown date, as
> currently https://meta.wikimedia.org/wiki/HTTPS binds resources.

Thanks Greg for the update! Now that the most hectic phase of current [[m:HTTPS]] plans is over, could we get more information and maybe a little urgent work on this?

Specifically, the biggest community concern is the lack of time after notifications. The notification system was already coded and notifications don't need 100.00 % perfect lists of affected users, so sending them should require little effort and make things much, much easier in a few weeks or months when resources will be found to actually implement the change.
Comment 15 Stefan2 2013-10-08 22:35:16 UTC
(In reply to comment #14)
> Thanks Greg for the update! Now that the most hectic phase of current
> [[m:HTTPS]] plans is over, could we get more information and maybe a little
> urgent work on this?

There is a note at [[User talk:Jdforrester (WMF)#SUL Finalisation]] which suggests that it won't take place within "the next few weeks" (as of 28 September). Also, does the information in that discussion mean that this bug is assigned to the wrong person?
Comment 16 James Forrester 2013-10-08 22:40:04 UTC
(In reply to comment #15)
> Also, does the information in that discussion mean that this bug is
> assigned to the wrong person?

{{fixed}}
Comment 17 Nemo 2013-10-31 13:51:01 UTC
I'm wondering how hard it would be for some community member to run a database query and produce a partial list of accounts which will be interested by this unification, so that we can start warning them and avoid last-minute panic. The 114,604 local accounts (as of 2013-05-16) clashing with a global accounts look like ideal candidates for a first batch of community notifications.
Comment 18 Andre Klapper 2013-11-22 15:39:43 UTC
dgarry: Any input / opinion on Nemo's last comment? Wondering how to move forward / what is currently blocking this ticket (and bug 39817).
Comment 19 Andre Klapper 2013-12-18 14:48:42 UTC
dgarry: Any input / opinion on Nemo's last comment? Wondering how to move
forward / what is currently blocking this ticket (and bug 39817).
Comment 20 Trijnstel 2013-12-18 20:53:44 UTC
(In reply to comment #19)
> dgarry: Any input / opinion on Nemo's last comment? Wondering how to move
> forward / what is currently blocking this ticket (and bug 39817).

I saw something regarding global rename (and thus SUL unification) here: https://en.wikipedia.org/wiki/Wikipedia:Bureaucrats%27_noticeboard/Archive_29#CHU.2FS_.26_CHUU
Comment 21 Dan Garry 2013-12-18 21:34:32 UTC
(In reply to comment #19)
> dgarry: Any input / opinion on Nemo's last comment? Wondering how to move
> forward / what is currently blocking this ticket (and bug 39817).

The blocker is basically me. I'm still new to product management and I need to sit down face to face with another product manager and be walked through this. Realistically this can't start until I'm relocated to San Francisco, which (fingers crossed) is next month.
Comment 22 MZMcBride 2013-12-18 21:53:21 UTC
(In reply to comment #17)
> I'm wondering how hard it would be for some community member to run a
> database query and produce a partial list of accounts which will be interested
> by this unification, so that we can start warning them and avoid last-minute
> panic.

It would be fairly simple to generate such a list. My concern is that someone, acting in good faith, would take the list and notify tens of thousands of accounts and create a false panic, particularly before the ability to globally rename a user exists (bug 14862).
Comment 23 Nemo 2013-12-18 22:09:21 UTC
(In reply to comment #22)
> (In reply to comment #17)
> > I'm wondering how hard it would be for some community member to run a
> > database query and produce a partial list of accounts which will be interested
> > by this unification, so that we can start warning them and avoid last-minute
> > panic.
> 
> It would be fairly simple to generate such a list. My concern is that
> someone,
> acting in good faith, would take the list and notify tens of thousands of
> accounts and create a false panic, particularly before the ability to
> globally
> rename a user exists (bug 14862).

Hm? The sooner local accounts are renamed, the better.
Comment 24 Nemo 2014-03-08 09:22:27 UTC
Given that it's now about 7 months with no movement here, FYI I'm available to act as (volunteer) product manager for this if WMF people are too busy with other things.
It's simpler for someone with years of experience in SUL as well as local, cross-wiki and global rename practices and otherwise (stewards are another group where it's easy to find such people).
Comment 25 Dan Garry 2014-03-19 21:55:24 UTC
I've got a plan afoot. Stay tuned for more information.
Comment 26 Nemo 2014-04-07 18:41:37 UTC
(In reply to Dan Garry from comment #25)
> I've got a plan afoot. 

I don't believe you.

> Stay tuned for more information.

I don't want to stay tuned, I have limited battery. Just transmit.
Comment 27 Amgine 2014-04-07 19:34:13 UTC
(In reply to Dan Garry from comment #25)
> I've got a plan afoot.

"Before the game is afoot, thou still let'st slip."
Comment 28 Dan Garry 2014-04-07 19:35:09 UTC
(In reply to Nemo from comment #26)
> (In reply to Dan Garry from comment #25)
> > I've got a plan afoot. 
> 
> I don't believe you.

Fortunately, this does not change my plans. :-)
Comment 29 MF-Warburg 2014-04-07 22:40:35 UTC
And that probably means "Fortunately, this does not change my plans in any way that will result in the fixing of this bug prior to 2016." :-(
Comment 30 PiRSquared17 2014-06-15 02:07:06 UTC
(In reply to Dan Garry from comment #25)
> I've got a plan afoot. Stay tuned for more information.

Bug 14862 is close to being resolved. Any news?
https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=116060#Next_month
Comment 31 Scott Martin (http://enwp.org/user:scott) 2014-06-16 22:34:19 UTC
(In reply to MF-Warburg from comment #29)
> And that probably means "Fortunately, this does not change my plans in any
> way that will result in the fixing of this bug prior to 2016." :-(

Hey, that'll make it a nice round ten years of not being done.

https://github.com/wikimedia/mediawiki-extensions-CentralAuth/commit/f34d746dd1133f42ad878c9ad3740148d6628c41#diff-78ccdd1419c89ebda99c7fe418fc64a1
Comment 32 Bryan Davis 2014-07-09 17:55:23 UTC
Making this a proper tracking bug by blocking bug 2007 and adding the tracking keyword.
Comment 33 Jarry1250 2014-08-21 22:00:26 UTC
Just to followup re: timescales for the casual bugspam follower, it's looking more like the first quarter of 2015 for this than 2016 (source: Dan Garry).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links