Openfoodnetwork: Email confirmation | Super admin adds new user

[daniellemoorhead]

Who: Super Admin wanting to register a user on the OFN.
How they access the sign up process: via the backend admin area that only the super admin can access.

---

Step 1(a): Super Admin signs up the user
The Super Admin accesses the add a user function in the backend and submits that user's email address and sets a password (existing functionality).

Note: we know that setting a password for a user is bad, and we've created #1612 to change this functionality so that the user sets it themselves.

[THIS REMAINS TO BE DONE >>>]

After submitting, a 'pending verification' message displays in the interface (new functionality):

Step 1(b): Super admin resends confirmation email to user
If the Super Admin needs to resend the confirmation email, they navigate to that user in the User section and click on the 'resend' link in the interface.

This triggers:

1. The same confirm email to be sent.
2. Success indicator - page reloads and the success banner shows
   

---

Step 2: System requests email confirmation
The completion of step 1 will trigger the system to do 2 things:

1. System creates a user record, flagged as unconfirmed.
2. System sends a confirmation email to the new user that includes a unique confirm link for that user.

---

Step 3: User confirms email
The user clicking on the confirmation link in the email will trigger the following:

1. System flags the user record as confirmed.
2. System sends the user a 'Welcome' email (generic email as in #1585)

---

Step 4: User logs in
Successful login from this screen will then close the modal and allow the user to continue browsing (existing functionality).

[myriamboure]

Today :
In “users” menu there are only the enterprise accounts (owner or manager, which are the only validated accounts today) + the users created by super admin. Today when a super admin add a user, the email is automatically considered as validated and the user receives directly a welcome email. It can be added directly as a manager or owner of an entreprise.

Desired behaviour:
When a super admin adds a user, a confirmation email is sent to validate the email. The user is considered as unconfirmed until the email has been validated.

List of things to adapt:

• [ ] 1- When super-admin add a user, an email confirmation message is sent to the user
• [ ] 2- When user click on validation link, open home page in new tab + send user welcome email

[sstead]

Existing behaviour:

• Superadmin creates a new user, and sets their password.
  
• A welcome email is sent to this user.
• If this user logs in, they can't get to /admin - they are like a customer user
• If SuperAdmin then creates a profile and assigns this users as the owner, the user gets an email confirmation email relating to the enterprise.
• If the user confirms their email, they're taken to login, and then once logged in they're directed to /register

[daniellemoorhead]

@myriamboure and @sstead given what Sally has described above, ie. the super admin can either create a general user or can create a profile and then assigns it to a user it feels like we may need to have 2 separate issues to cover this. What do you think?

[daniellemoorhead]

@sstead answers to your questions:

? Should SuperAdmin be able to 'manually verify' a user?

Absolutely not. That defeats the purpose of email verification whereby the email address owner is the one to verify.

? Should SuperAdmin be able to assign a unverified user as manager or owner of an enterprise?

Does the Super Admin do this in the same way that an enterprise owner does, through the same interface as the owner? If so, then this scenario is covered by #1593.

[myriamboure]

"the super admin can either create a general user or can create a profile and then assigns it to a user it feels like we may need to have 2 separate issues to cover this. What do you think?"
For me it is already covered in https://github.com/openfoodfoundation/openfoodnetwork/issues/1593 so we don't need to create a separate issue @daniellemoorhead

[myriamboure]

@Matt-Yorkley I added the "THIS REMAIN TO BE DONE" title on what needs to be done: display the "email confirmation message has been sent" message on user profile to enable super-admin to know this user has not confirmed + resend confirmation if needs be.

[myriamboure]

:point_up: @Matt-Yorkley going though email project, seems that this one can go next whenever you can :-)

[HugsDaniel]

So if I got this right, what is to be done is end of Step 1a : After submitting, a 'pending verification' message displays in the interface (new functionality); and Step 1b.
Is that correct ?

[HugsDaniel]

For user creation on admin side, controllers, routes and views are Spree's. There are no mentions of any implementation of this kind in Spree 2.0, so in order to add custom methods and views in OFN, we would have to override somehow Spree::Admin::ResourceController#create and Spree::Admin::ResourceController#update. Or maybe it can be done via the email confirmation sender. What do you think team ?

[myriamboure]

Yes @HugsDaniel that's what is remaining. Probably @Matt-Yorkley can have good tips for you as he has worked on most of the email confirmation job :-)

[myriamboure]

Any news @HugsDaniel on this one? Did you get support from @Matt-Yorkley on your question? Else maybe @mkllnk or @sauloperez can answer your question?

[mkllnk]

I think long term we would like to get away from all Spree views. How much effort would it be to re-implement the admin users controller? It seems like a simple interface. We can then customise it however we like.

[sauloperez]

that could be a good spot to try out this idea of having our own views instead of relying on Deface. We can give it a try and then see if it fits our needs and we all like it.

[kirstenalarsen]

and that will be helping us decouple a bit from Spree? she says hopefully?

On 24 May 2018, at 4:32 AM, Pau Pérez Fabregat [e-mail] wrote:

that could be a good spot to try out this idea of having our own views instead of relying on Deface. We can give it a try and then see if it fits our needs and we all like it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/openfoodfoundation/openfoodnetwork/issues/1589#issuecomment-391452050, or mute the thread https://github.com/notifications/unsubscribe-auth/ACxryO7nFscDv71fYKae1aQqjkDHxJ62ks5t1asngaJpZM4Nojr0.

[mkllnk]

Yes. @HugsDaniel Are you happy to try it out?

[HugsDaniel]

@myriamboure I'm going full time on Spree upgrade with @sauloperez as discussed today, so I'll leave this one for now. Maybe someone else would like to tackle it ? @mkllnk ?

[myriamboure]

Ok, cool that you focus on Spree upgrade ;-) @Matt-Yorkley or @mkllnk can one of you assign yourself on it? We ony have 3 left issues to finish email confirm!!! The 2 others are on Matt so far.

[mkllnk]

Okay, I'm taking this on.

Just a comment on what @daniellemoorhead wrote:

? Should SuperAdmin be able to 'manually verify' a user?

Absolutely not. That defeats the purpose of email verification whereby the email address owner is the one to verify.

I think I agree that the admin should not be able to "verify" the email. But we recently had the problem with the US instance that emails were not working. There was no way to allow a new user to be admin to fix the email configuration. They couldn't log in. So I think in an ideal world, we would have email verified and allowed to log in as separate properties. I'm not proposing to do this now. It's just an idea to keep in mind in case we have a similar problem again.

[sauloperez]

but that can be solved by changing things from the rails console or DB directly in production. If it rarely happens I'm not sure it's worth separating these properties.

[Matt-Yorkley]

I think this issue might also benefit from moving away from spree/deface and recreating our own fully custom view for this admin user edit page.

[mkllnk]

I submitted #2394 which adds the notification and the resend button. It doesn't change the confirmation email text though. I spent a while trying to alter that, but I think it should go into a separate pull request. There is also no nice and easy solution for it. @myriamboure How important is that text change? Can we write a generic email that covers all scenarios? I can do it, but it may take a whole day to implement it. If we still want to do it, we should probably open a new issue for that.

For any dev reading this: The email sending is triggered on the user model on create. We can override that method on the model, but we would need to know if the user was created by admin or by a guest. This information is in the controller, not the model. So we would need to alter Spree's user controller, to store in the model if it has been created by an admin. That flag can then be used when sending the email. Do you have a better idea?
One alternative I can think of: Deactivate the automated sending of emails on user creation and add that action to controllers creating a user. This way it's more explicit. It also means that no email is sent when creating a user from the console or a migration. Actually, rake db:seed is probably sending an email at the moment and we could avoid that, because the first user is confirmed anyway. Yeah, this might be the better way. Less magic, more explicit code.

[myriamboure]

Current confirmation/resend confirmation email is:

It is ok for me to leave it as it is for now, I guess if we add a user from admin the user will know, and admin wouldn't do that without a user requesting it.
If we realize later on that there are confusion and there is a need to clarify I suggest we change the message to make a more generic one that include both cases. But let's not do it now as I don't think there is a need really.
So I propose we don't go further and just test and merge your current PR, thank you @mkllnk for proposing that and not spending too much time on it for low value added ;-)