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
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | Picture 1.png | 17.68 KB | greggles |
| #8 | 590150_bakery_self_serve.patch | 13.49 KB | greggles |
| #4 | bakery.patch | 12.31 KB | bdragon |
Comments
Comment #1
gregglesFor documentation of the current process...
Comment #2
litwol commentedaddon 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.
Comment #3
bdragon commentedClaiming.
Comment #4
bdragon commentedHere'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:
Comment #5
joshk commentedTested 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!
Comment #6
gerhard killesreiter commentedI am ok with this.
Comment #7
joshk commentedOk, I'm going to roll this in and put it on g.d.o this weekend if nobody objects.
Comment #8
gregglesI 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.
Comment #9
gregglesFixed http://drupal.org/cvs?commit=290942
Thanks, bdragon!