You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, if a user makes a login.gov account and logs into our system, a User record is made for them (lets call this account A). Then, if this user deletes their login.gov, this User record will still exist in our system. If they then make a new login.gov account and log into our system a new record is made, we'll call this record B. This user then gets a 500 error because our code is expecting there to just be 1 user per person, and the email field should be unique on each record.
We know login.gov does not let you have two active login.gov accounts with the same email address, thus we know for sure that account B will also be the active login.gov account and account b is deactivated or no longer associated with this email address. That said, we should stop giving 500 errors to our users and instead update the record for account A with account B's UUID and not generate a new record. This avoids us ever having duplicate Users in the future.
Acceptance criteria
do not create User records with an email address already in the system, instead update the existing User record to have the new UUID
update fixtures so that it won't create a User record with a duplicate email to one already in the system (this would create a hole in our logic), have fixtures update the matching User record instead with the UUID from fixtures (see additional context)
Additional context
Note on fixtures AC:
right now on staging we copy all the data from stable, then label fixtures on top. This means anyone who has their same work email address on stable and is in fixtures then has two entries on staging (one user record from fixtures running and one user record from the db copy). The database copy runs first, so we should just update fixtures so that if a user record with the same email address as an existing record will be created it just updates the UUID and other values in that record accordingly.
Additional reason for this ticket:
It was fine-ish for us to give a user a 500 error, but now in the org model we will be sending invitations for users based on their email and will hit another 500 error if anyone invites a user who has a duplicate user account. For instance, if an admin adds domains or invites a user to a portfolio when they have 2 user accounts then it's the admin that will see a 500 error and it will appear our system is broken. They also will not be told why or how to fix it. To get around this we could add in nice user facing messages, but that overcomplicates various areas of our code even beyond org model.
Links to other issues
No response
The text was updated successfully, but these errors were encountered:
Issue description
Right now, if a user makes a login.gov account and logs into our system, a User record is made for them (lets call this account A). Then, if this user deletes their login.gov, this User record will still exist in our system. If they then make a new login.gov account and log into our system a new record is made, we'll call this record B. This user then gets a 500 error because our code is expecting there to just be 1 user per person, and the email field should be unique on each record.
We know login.gov does not let you have two active login.gov accounts with the same email address, thus we know for sure that account B will also be the active login.gov account and account b is deactivated or no longer associated with this email address. That said, we should stop giving 500 errors to our users and instead update the record for account A with account B's UUID and not generate a new record. This avoids us ever having duplicate Users in the future.
Acceptance criteria
Additional context
Note on fixtures AC:
right now on staging we copy all the data from stable, then label fixtures on top. This means anyone who has their same work email address on stable and is in fixtures then has two entries on staging (one user record from fixtures running and one user record from the db copy). The database copy runs first, so we should just update fixtures so that if a user record with the same email address as an existing record will be created it just updates the UUID and other values in that record accordingly.
Additional reason for this ticket:
It was fine-ish for us to give a user a 500 error, but now in the org model we will be sending invitations for users based on their email and will hit another 500 error if anyone invites a user who has a duplicate user account. For instance, if an admin adds domains or invites a user to a portfolio when they have 2 user accounts then it's the admin that will see a 500 error and it will appear our system is broken. They also will not be told why or how to fix it. To get around this we could add in nice user facing messages, but that overcomplicates various areas of our code even beyond org model.
Links to other issues
No response
The text was updated successfully, but these errors were encountered: