Sharing a plan logic and creating new account logic - request to change

[magdalenadrafiova]

Expected behaviour:
Regardless creating the account first rather than just following the link to access the plan the user should be able to see the plan that was shared with his/her email address.

Actual behaviour:
Scenario A: Receiving an invitation for plan but rather than following the link creating own account first on dmponline
1, Created a plan as mdrafiov@ed.ac.uk and shared with new email address (new account) dmponlinetestmagdalena@gmail.com
2, I logged in into the new email address dmponlinetestmagdalena@gmail.com and rather than following the link for the plan I followed the link to dmponline and created a new account on DMPonline as a user
3, when I created the new account as dmponlinetestmagdalena@gmail.com the plan for which I made myself co-owner was not in my dashboard although account from which I shared this with said it is being shared with this email address
4, when I shared again from mdrafiov@ed.ac.uk with the new account dmponlinetestmagdalena@gmail.com I have received the email and this time when I followed the link I was able to access the plan
5, when I followed the link after I already created account on DMPonline (copy and paste or just click) it worked well

Scenario B: Receiving an invitation for plan and adding just my password
1, Created a plan as mdrafiov@ed.ac.uk and shared with new email address (new account) dmponlinetestmagdalena2@gmail.com
2, I logged in into the new email address dmponlinetestmagdalena2@gmail.com and this time I followed the link for the plan and just added my password and I was directed straight to see the plan

Steps to reproduce:
I am not sure what is exactly the logic behind this, but either:

1. make the link to expiry after two weeks so in a case the user never follows the link he/she can still create the account and access the plan
   2, even if the right logic is not followed (following the link and creating the account first) the user with the identical email address should be able to still see the plans that were shared with him/her

[sjDCC]

This logic is intentional and was the result of issues we encountered when plans had been shared and the user never followed the invite link. As this process creates a stem account for that email, this person was not able to create a new account and had to find the old invite link, which was not always possible.

As a solution, we allowed people to create accounts separately to invites and overwrote any plan shares as a result since the account creation was happening separately to following the invite link. Another option could be to set an expiry on the invite link.

Will leave this open for devs to consider, but I suspect neither route will be perfect

[briri]

It would be worth reviewing the documentation for the Devise libraries we use to manage these security features. We are on the current versions but its possible that we are not taking advantage of all the latest features.

• https://github.com/heartcombo/devise
• https://github.com/scambra/devise_invitable

The original issue was that creating an account tries to insert a new record into the database. The database though requires that the email address be unique. Inviting a user creates a stub account (as you said @sjDCC above) so the account creation fails.

The code in the 3 controllers that manage user authentication are overly complex and could use a little TLC.

• https://github.com/DMPRoadmap/roadmap/blob/master/app/controllers/registrations_controller.rb
• https://github.com/DMPRoadmap/roadmap/blob/master/app/controllers/users/omniauth_callbacks_controller.rb
• https://github.com/DMPRoadmap/roadmap/blob/master/app/controllers/users/invitations_controller.rb

If Devise doesn't provide an easy fix for this, it should be relatively easy to just check if the user has an invitation record already and then accept the invitation and finish the account sign up. It would be great to reevaluate and clean all of this up though.

[sjDCC]

There were several tickets on same issue #2260 and #2407 have been closed. Left this one open in case devs want to clean up logic

[mariapraetzellis]

@briri will consider this issue & close if necessary.

[briri]

I think this is worthwhile. We can probably just add some logic that retains the user's relationship with the shared plan when their account is created.

[briri]

Fixed in PR #2946