I think we need a system for people to have self service account synchronization. The workflow would be something like:

1. User attempts to login to subsite
2. Subsite says "name is already registered, would you like to claim it?"
3. User clicks to claim and sees a form with a username and password field - username is pre-populated but can be changed
4. User enters the username and password for the subsite, the subsite's bakery module magically updates the init, and e-mail address columns.

One wrinkle comes from situations where Bakery tries to merge with the "wrong" account which is why they can use whatever username they want in step 3. However, we still probably need a way for people to merge accounts. I've already written this module and will polish it up and release it soon for review prior to installing on g.d.o The mergeuser module follows a similar method saying

1. enter username and password for account you want to merge
2. it calls a hook for modules to do the right thing for the merge
3. at which point they update database columns - hooks for user, profile are done, OG is still needed

Comments

greggles’s picture

For documentation of the current process...

  1. A user sends a mail or submits a request pointing to a UID on g.d.o and one on d.o that are the same
  2. Optional: sometimes the mail or username is already taken, so the duplicate accounts have to be modified to make the username/mail available for the account that is being synched
  3. An admin user has to get involved and edit the usernames and mail fields to make sure they are the same
  4. An admin user with db access has to get involved and update the database - the users.init field is set to http://drupal.org/user/UID/edit and the users.migrated field is set to 1
litwol’s picture

addon to option 2 in #1: Since we pretty much automatically wipe out g.d.o created accounts, we need to send out an email to the current accunt holder before the takeover notifying them of the event. They will receive a post-factum email, but at least that gives them some information on what happened and chance to "handle it" later. Also if a user comes back to us with such email, it gives us a trailback. My take on it is if a user didnt come back to us, the trailback is not important.

bdragon’s picture

Assigned: Unassigned » bdragon

Claiming.

bdragon’s picture

Status: Active » Needs review
StatusFileSize
new12.31 KB

Here's what I have so far.

I may be coding a bit too defensively when it comes to {users}.init, but as that field isn't unique, it really needs to be watched carefully.

Also, it would be a very good idea on largeish sites to add an index on {users}.init to speed things up.

States a user can be in:

A) username and mail both match -- they get logged in because that's the criteria for logging in with the cookie
B) username matches, email doesn't -- Fixable with confirmation
C) username differs, email matches -- Fixable with confirmation
D) username matches one account, email matches another account -- Only fixable by manual process because both accounts will need to be modified because only one user can have the same name and only one user can have the same email
E) Username and email match, but init is wrong -- Means that if the user makes changes on their master account it will go out of sync. This is fixable automatically.
F) Username and/or email differ, but init matches -- This is fixable automatically.
G) Any of the above, with the additional problem that a DIFFERENT account has a matching init. -- This is bad.
H) Multiple accounts with matching init. -- This is bad.
joshk’s picture

Tested this out and it works well. The code also looks decent. +1 for keeping up with the whimsical function names.

This will help us out going forward on g.d.o, but we should be aware it won't resolve accounts where the names AND emails are different (which is a non-trivial set). Still, it should be included IMHO, as it makes Bakery more usable by the wider world.

The only thing I'd like to see for this is some better bakery_uncrumble_submit() comments and function documentation.

If possible we should get a second set of eyes on this, but it worked well for me and the code is nice and clean. Great job BDragon!

gerhard killesreiter’s picture

I am ok with this.

joshk’s picture

Ok, I'm going to roll this in and put it on g.d.o this weekend if nobody objects.

greggles’s picture

StatusFileSize
new13.49 KB
new17.68 KB

I tested out a few scenarios and they worked as expected.

There were some undefined notice errors which I fixed.

There's also the problem that this current patch shows a green message underneath the error message (see attached screenshot). I don't think the error messages are useful any more so I removed them, but we should have a "for more info/alternative" message somewhere so I added an admin configurable message for that.

Updated patch attached. I'd love to roll this out soon. I just worked through 200+ people manually today. It is teh suck.

greggles’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.