Kuma: Send Recovery Mail for existing Persona accounts

[schalkneethling]

On the signup page there is the following code block:

{# we have to handle this error message here to have access to the request #}
{% if error == form.duplicate_email_error_label %}
  {% trans login_url=url('account_login'), next_url=github_connect_url, provider_name=provider.name %}
  A profile already exists with the selected email address.
  <a href="{{ login_url }}" class="launch-login" data-next="{{ next_url }}">Connect your
    {{ provider_name }} account to it.</a>
  {% endtrans %}
{% else %}

From some testing(https://github.com/mdn/kuma/issues/5909#issuecomment-543634445) and speaking to @escattone it seems that the duplicate email constraint was never, or is no longer enforced.

@atopal Suggested that we look into the viability of(the amount of effort that will be required):

1. Detecting that the current user has an existing Persona account(https://github.com/mdn/kuma/issues/5909#issuecomment-543151435) that matches their Github account(I assume this will be based on the email address and not the username)
2. Automatically trigger a recovery email for the user without any user action
3. Provide a notice to the user in the UI that a recovery email has been sent and to which address
4. Determine the process flow a user would currently follow to recover their email

[atopal]

Sorry, there was a misunderstanding, my suggestion is that if we receive a validated email address that matches an already existing persona one we simply recover that account as part of the process, no emails being sent.

[tobinmori]

@atopal Ryan and I checked this out and found 160k Persona users.

Question 1: What do you prefer we do once we discover that someone attempting to log in was once a Persona user?

1. delete the Persona acct in the background, and let them create a brand new social acct.
2. before deleting Persona acct, copy over the user's profile metadata (interests, TZ, locale, github/twitter/linkedin/fbook urls) - once they create a new social acct. (we'd have to copy over this data after the user has created their new social acct, so that we can assign the metadata correctly) - in this case, we could ask the user if they wanted his data migrated (this would be more effort)

Question 2: what to do with a Persona user who has been banned? (stored in the MDN user acct)

[atopal]

Q1. Let’s go with option 1. They haven’t seen that data in at least 3 years.
Q2. Let’s ignore their banned status. This will most likely be extremely rare

[jmswisher]

Q2. Let’s ignore their banned status. This will most likely be extremely rare

Also, banning is usually about spam. If they're creating a membership account, they won't have edit access, so they won't be able to create spam. (However, we might want to prevent them from enabling edit access. But probably so rare a case as to be not worth spending any time on.)

[escattone]

@atopal @schalkneethling After looking at this in much more detail today (the code is not easy to grasp), I realized that this is more complicated than I originally thought (for example, deleting the user associated with an existing persona account may not be straightforward since that user may have made one or more document revisions). Now that I understand this user/social-account world much better, I think it would be really helpful if we could set-up some time to discuss this in a zoom meeting. Would that work for both of you?

[atopal]

Happy to meet, Ryan.

[tobinmori]

@escattone what else needs to be completed on this one?
And, is this estimate still accurate?

[tobinmori]

@escattone we should close this ticket and create a new one with acceptance criteria for the actual work. Can you do that?

[escattone]

@escattone we should close this ticket and create a new one with acceptance criteria for the actual work. Can you do that?

Yes, I think we should close this one, and I'll create a new one, thanks @tobinmori.

[escattone]

Closing this issue in favor of https://github.com/mdn/kuma/issues/6182