meteor-accounts-meld will lose ID of original user

[calvinfroedge]

Hi Luca,

I just want to point out that despite your great work on this package, there is one consequence that users should be aware of (Perhaps it should be added to the README?)...

    // Removes the old user
    Meteor.users.remove(srcUser._id);
    // Updates the current user
    Meteor.users.update(dstUser._id, {
        $set: _.omit(dstUser, "_id", "services")
    });
    Meteor.users.update(dstUser._id, {
        $set: newServices
    });

If a user has an existing account, and logs in with a new provider, he gets the ID of the new account. This may destroy relationships with other collections as well as other systems (not part of the meteor app, but part of the same tech infrastructure, such as a search index or a postgres database, redis store, etc.) that user the user ID.

I think that you may have implemented it this way to preserve the existing new login session the user establishes (i.e., he logs in as a new user, and you don't want to remove THAT account), but it does create a data integrity issue.

[splendido]

this is exactly the reason why a couple hooks have been introduced:

• meldusercallback
• melddbcallback

the first paragraph from the first link begins with:

One of the aim to accounts-meld is not to loose anything about any two melded accounts!

while the second sections begins with:

Another callback not to loose anything can be provided (and should be) to let you change any reference to the src_user._id you might have inside your DB. This is where you can migrate documents belonging to (or simply referencing) the user that will be deleted to the one that will survive.

Do you think this is not clear enough?

Please let me know how would you put it, since I'm not native English and sometimes I might read/write things a little weird.

Obviously, PR are always welcome!

[revmen]

I think you did a decent enough job of explaining what happens and giving hints about how to compensate for it.

But it seems un-intuitive to me that the original account is the one that's destroyed. Wouldn't it be a more common scenario that you'd want to keep the old account and simply add to it the service being used to log in with the new account? Is there a reason the default behavior is to keep the new account and blow away the old one?

[ghost]

I agree - I would like to be able to choose to have the old account survive. The use case I see is that a user signs up with Google and uses the applicatin, then decides to register with their email address (and gets a verification email) - once they have verified their email anything they have done previously could be lost. I would prefer to be able to keep the older account and lose the new one.

[guilhermedecampo]

@blorriman :+1:

[elie222]

agreed. the old account should survive

[ujwal-setlur]

Agreed, older account should gobble up the new one. The new account will likely not have data associated with it that would need to be migrated. But I am glad these hooks are there. That should do for my use case.