Confirmation Email functionality is overridden when an email update is pending
Problem
A Customer recently reported weird behaviour when trying to change their primary email account email, which is tied to an existing user account. I've sanitised emails to provide an example:
- Account 1:
john@example.com
. Account already exists. Has an active subscription, but the customer wants to change this tojsmith@example.com
. - Account 2:
jsmith@example.com
. Account exists, but has not yet been confirmed via email.
- The user tries to initiate a change of the details from
john@example.com
tojsmith@example.com
. They are informed a confirmation email will be sent to the intended email address for the transfer. -
jsmith@example.com
receives the transfer email, and is asked to confirm the action. The user follows this link, but is informed that the email 'has not been confirmed', so the transfer action doesn't complete. - The user initiates a confirmation email request (
https://customers.gitlab.com/customers/confirmation
) to confirm theirjsmith@example.com
account, but the Mailer just re-sends the transfer email seen in Step 2.
Due to the intended account not being confirmed, the user is unable to proceed. Could this be because the intended user account both exists in the system, but is not considered a full account because it is not yet confirmed? I'm unsure why the confirmation request email is re-sending the transfer confirmation email.
Proposal
- Implement a solution to avoid this 'limbo' state for user
jsmith@example.com
. Perhaps follow a similar strategy to GitLab.com and delete unconfirmed accounts after a short period of time to free-up the email. - Allow the confirmation mailer to send the intended original 'confirm your account' email, to allow the user to log in to
jsmith@example.com
.