Openfoodnetwork: Email confirmation | Verifying email addresses of existing users in the system

[daniellemoorhead]

NEW 'YOU MUST VERIFIY YOUR EMAIL BEFORE YOU CAN DO THAT' CONDITIONS (DRAFT)

CASE 1/5- If an existing, unverified user tries to shop in a 'customer only' shop?

Currently the logged out user who tries to access a 'customer only shop' will see a message saying 'you need to login to view this shop'. They can then either login, or signup (the signup case is covered in https://github.com/openfoodfoundation/openfoodnetwork/issues/1586).

The existing user logs in:
Once they login, the system currently checks whether the user is on the shop's customer list, or not.

• [ ] i) If the user is NOT on the shop's customer list, they should be shown the existing message:
  
• [ ] ii) If they ARE on the list, it should now also check that they are a 'verified' user.
• [ ] iii) If they are on the shop's customer list AND they are verified, they can proceed to the shopfront.
• [ ] iv) If they are on the shop's customer list and they are NOT verified it should show them a message such as:
  

• [ ] v) When this screen is shown the email verification email should go to the user automatically. ? Should their verification link bring them back to this specific shopfront, or is the homepage ok?? Depends on the difficulty level of creating a specific link?
• [ ] vi) The user should also be given the option to resend the verification email. When they do this a green banner should read 'verification email sent'.
• [ ] vii) This user can remain logged in, and they can continue to do everything else they would normally do, except shop at this shop? Is this correct?

CASE 2/5 - If an existing user who's never verified their email tried create an enterprise?
Assuming they don't already own/manage any enterprises, thus they'll create the enterprise from /register, not from the backend.

• [ ] i) The user will go to /register and be prompted to login

• [ ] ii) Once they have logged in, or if they were already logged in, they will see the same 'you need to verify your email' message as in point 2 of https://github.com/openfoodfoundation/openfoodnetwork/issues/1585.

• [ ] iii) Points in https://github.com/openfoodfoundation/openfoodnetwork/issues/1585 will apply to this user when they try to access /register. However, they should remain logged in even though they are not verified. All of their existing experience should remain the same (e.g. they can view their Account page with past orders, and they can place orders), the only difference is that when they try to access /register they cannot proceed unless verified.

CASE 3/5 If a user want to access his guest orders history
We can include in the guide/FAQs that if a customer wants to see their past guest orders they must a) signup and b) verify their email.
Remember this user could be:

• Someone who is not an existing user, and has placed guest orders. This user only needs to signup and they will automatically see their past guest orders as part of https://github.com/openfoodfoundation/openfoodnetwork/issues/1592 once they verify.

• Someone who is an existing user, who is not verified, and who has also placed guest orders...
  This person needs to verify before their guest orders will be linked. Where is the best place for an existing user to do this? Suggestions below:
  
  or
  

EDGE CASE 4/5 If an enterprise owner adds a non-verified existing user as a manager, in the manager field, or the notifications field.
An owner can add a manager via the 'Manager' field. This user can be an existing unverified enterprise or shopper user. As long as I type their entire email into the field, I can add them as a manager.

• [ ] When a owner does this, the system should check if that user if verified. If they are not, they should be sent an email verification. This email should read 'You've been added as the manager of XXX on the Open Food Network. To manage the profile you must first confirm your email'.
• [ ] Until that user verifies their email, they should be a 'tentative manager' with a message like this -
  as seen by the owner.
• [ ] Until that user verifies, the owner should NOT be able to make them the new owner of an that enterprise.
• [ ] When this new manager user logs into OFN (while still unverified) they should have full access to things unverified users can access (e.g. shops, their account). But if this user tries to access /admin, they need to be reminded to verify. So I suggest they can see the Administration link in their Cog menu, but if they select it, they are prompted to verify or resend the link in a modal.
• [ ] The verification link this person receives should take them to /admin.
• [ ] Their 'thanks for confirming' email should also be different to a regular confirmation email. Perhaps just reading 'Thanks for verifying your email. You can now access your enterprise at /admin'.

EDGE CASE 5/5 If an enterprise owner adds a non-verified user, or a new user, in the Notifications field.
An owner can type a new email into the notifications field.
i) If that user is verified, they are made a manager instantly and they become the notification email (existing functionality)
ii) If that user is new, they are sent a verification email. When they confirm this email, they are made a manager and they become the notification email (existing functionality).
iii) If that user is existing, but not verified, we need to do the following:

• [ ] They should be sent an email verification. This email should read 'You've been added as the manager of XXX on the Open Food Network. To manage the profile you must first confirm your email'.
• [ ] Until that user verifies their email, they should be a 'tentative manager and tentative notification email' with a message like this -
  as seen by the owner.
• [ ] Until that user verifies, the owner should NOT be able to make them the new owner of an that enterprise.
• [ ] When this new manager user logs into OFN (while still unverified) they should have full access to things unverified users can access (e.g. shops, their account). But if this user tries to access /admin, they need to be reminded to verify. So I suggest they can see the Administration link in their Cog menu, but if they select it, they are prompted to verify or resend the link in a modal.
• [ ] The verification link this person receives should take them to /admin.
• [ ] Their 'thanks for confirming' email should also be different to a regular confirmation email. Perhaps just reading 'Thanks for verifying your email. You can now access your enterprise at /admin'.

[myriamboure]

For me an unconfirmed users can still login and checkout as a registered user without their email being validated (all current users for instance) so we don't have to try to verify email addresses of existing users until they want to do something that requires their email to be verified, in which case we would resend confirmation email https://github.com/openfoodfoundation/openfoodnetwork/issues/1590

OR should we force validation of ALL users as soon as possible, and why ?
In that case I would suggest we just make logged-in checkout impossible if email is unconfirmed. So if a unconfirmed user tries to checkout, we display a page saying that a confirmation message has been sent to validate their email before they can proceed to checkout. They have to click on the link before they can order. That would "force" email validation, but it might be a bit hard for the user to understand why we ask to confirm their email now...

Any preference or idea @daniellemoorhead @oeoeaio @sstead ?

[sstead]

_We don't have to try to verify email addresses of existing users until they want to do something that requires their email to be verified_ ... what does this include?

• If they try to shop in a 'customer only' shop?
• If they try to create an enterprise?

_OR should we force validation of ALL users as soon as possible, and why ?_
I'm not sure I'm the best to comment on the security implications of this. From a user perspective they probably don't want to be hassled to confirm their email. But there may be a secuirty reason why it would be worthwhile.

[myriamboure]

Yes @sstead and I would add a third case "if a user want to access his guest orders history" (see https://github.com/openfoodfoundation/openfoodnetwork/issues/1590)

@oeoeaio do you see any security reason why we should force all existing users to confirm their email ?

[sstead]

Just spoke to @oeoeaio and he's happy for existing unconfirmed users to remain so, until they try to do something advanced.

[daniellemoorhead]

Ping @myriamboure @sstead @oeoeaio for your thoughts

Myriam, some context for you - Sally, Rob and I chatted about existing users today, and used the whiteboard to map out what we could do with them based on the solution we've designed for new users.

Here's a pic of the whiteboard:

So, given the current scope of work we think there is one thing we must do (map the verified enterprise email address to the user, #1614), and then 2 possible options we could choose from for dealing with existing users:

1. We require all unverified users at the point of login (rather than just any new users that sign up once user email confirmation functionality is launched) to confirm their email before they can login. This means that stories #1615, #1616, #1617, #1618, and #1619 would be relevant for all users, not just the new ones.

PROS: We'll have all active users email verified, and connected to their guest checkout record if one exists.

CONS: We're introducing a barrier to entry for existing users, which may annoy them. But if we structure the message on the login modal well enough, then they'll at least understand why we are making them take this step (ie. account security).

_Plus as an optional extra:_ We set up a 'blanket' confirm request for all unconfirmed users, regardless of who they are or if they're active or inactive. This would be the sending of an email to any unverified users asking them to confirm their email address for OFN.

PROS: Gives us an opportunity to bring inactive users back to the website and re-engage them.

CONS: Means extra work on our part, and may annoy any users who aren't using OFN.

1. We only require verification for users trying to access particular parts of OFN:
   a. Any users accessing /admin
   b. Any users accessing /accounts
   c. Any users accessing /register
   d. Any users accessing customer-only shops

PROS: We're only prompting for confirmation for those areas of the site where it's needed, so not all users are affected. Less of a barrier to entry for them.

CONS: Data consistency is lacking in that we don't have all users verified. Maybe this isn't really a problem, but the neatness of the 'across-the-board' solution for all users seems better for data integrity than only for some. Also, it may be extra work to set up this verify request at particular points in the platform rather than at the point of login.

Thoughts? Which should we choose?

[sstead]

Well summarised @daniellemoorhead .
Option 1 seems very clean to me, plus it's easier (i assume) and cheaper to implement. I might be biased because I find mapping out all the user journey's very complex!

[myriamboure]

I'm not sure I understand everything but I get the most important I think, thanks for sharing @daniellemoorhead and thanks for all your workon it :-)

Option 1 seems ok to me, especially if we say something like "to ensure the security of your account we have sent you a link to confirm your email blablabla", I think it's ok to ind of "force" users to all confirm their email before being able to login... so that way, we won't have to deal with any "unconfirmed user" as they would all have to confirm when loging in.
About the "extra" option 1, I don't think sending a message to an inactive user asking him to confirm his email will bring him back .... I am not in favor of it, also because lots os customers don't really pay attention about the OFN, they are connected to a hub brand. It would be counter productive, and anyway they will never ALL confirm, so we will always have unconfirme user, but they won't be able to login anymore before they have confirmed their email.

As there is a bit of uncertainty around all that still (from what I understand) I think it's ok to force confirmation for login, I guess it might save us some future efforts, let's adopt a permaculture principle and do things in a way that will save us future work :-)

[daniellemoorhead]

@oeoeaio agreed after discussion that we should go ahead with Option 1.

This being the case, we no longer need this separate issue to deal with existing customers, they're being included in stories #1615, #1616, #1617, #1618, and #1619. So I'm closing this one but leaving it attached to the epic so that others can see the thinking that went into this decision 😄

[myriamboure]

I think it does make one slight difference though @daniellemoorhead : if an existing user login (before shopping, or at checkout) IF his email is not verified, even if he doesn't want to do anything advance, he is sent an email confirmation and the message ""to ensure the security of your account we have sent you a link to confirm your email blablabla"" is displayed. He can't continue login until he has verified his email. That way we will clean the whole database of active users and they will all get confirmed. That's what I understood in option 1, am I right ? So in https://github.com/openfoodfoundation/openfoodnetwork/issues/1617 and https://github.com/openfoodfoundation/openfoodnetwork/issues/1616 it concerns not only new users but also existing ones am I right ? Just to clarify my understanding and be sure we are on the same page ;-)

[daniellemoorhead]

So in #1617 and #1616 it concerns not only new users but also existing ones am I right ?

This is correct @myriamboure, I'll be changing these issues on Sunday to reflect the updated scope. You can see I've started doing this on #1585, combining Sally's notes and screenshots with a step by step view for the developer to quote on and then build.

[myriamboure]

Ok sorry @daniellemoorhead I didn't know I could comment without re-opening the issue, closing again ;-)