Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meteor-accounts-meld will lose ID of original user #28

Open
calvinfroedge opened this issue Oct 18, 2015 · 6 comments
Open

meteor-accounts-meld will lose ID of original user #28

calvinfroedge opened this issue Oct 18, 2015 · 6 comments

Comments

@calvinfroedge
Copy link

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
Copy link
Owner

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

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
Copy link

revmen commented Nov 12, 2015

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
Copy link

ghost commented Jan 19, 2016

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
Copy link

@blorriman 👍

@elie222
Copy link

elie222 commented Apr 10, 2016

agreed. the old account should survive

@ujwal-setlur
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants