Jason-Gush
commented
4 years ago Problem is that the user is created on invite and the task associated with them. Sticky to unpick.
Closed Jason-Gush closed 1 year ago
Jason-Gush
commented
4 years ago Problem is that the user is created on invite and the task associated with them. Sticky to unpick.
Jason-Gush
commented
4 years ago At a minimum we need to change the warning, alternative action is for the admin to edit the users email but let's discuss the implications next catchup.
rpaw053
commented
4 years ago Problem use case:
The below message is only shown for user who has two different emails associated with one organisation and tries to link ORCID iD.
Danger! This {ORCID ID} is already associated with other email address of same organisation: {ORGANISATION}. Please use other ORCID iD to login. If you need help the kindly contact orcid@royalsociety.org.nz support for issue
Solution:
If user has already link ORCID to its email(for e.g. xyz@gmail.com), and is invited again by the same organisation on new email address(for e.g xyz@institution.org.nz) and goes through the ORCID flow with new email address(xyz@institution.org.nz), so here instead of showing them Danger message show them a page where can select between two email address ( the old email address xyz@gmail.com and new email address xyz@institution.org.nz).
Also show them the message that they can only have one email address associated with one organisation and they need to choose which one they want to keep.
Depending on their choice:
case 1: They choose new email address (xyz@institution.org.nz), so now HUB will select the old user account which has xyz@gmail.com and override the email address xyz@gmail.com with xyz@institution.org.nz and delete the newly created account which has email xyz@institution.org.nz. for auditing save this transaction in seperate table with timestamp, old email address and new email address, and user's choice.
case 2: They choose the old email address (xyz@gmail.com), so now HUB will allow the login using old user account (xyz@gmail.com) and then delete the new user account which has xyz@institution.org.nz, for auditing save this transaction in same table mentioned in case 1.
Testing:
[ ] Test all the above scenario.
[ ] Test ORCID permissions deny flow
[ ] Test what happen if user clicks the invitation link multiple times.
[ ] Check what happens when user clicks the new invitation link again, even after going through the flow where we delete the new account.
[ ] Test user having multiple emails associated with multiple organisation (we wont be touching this flow, so just testing is needed if this works as expected)
[ ] Test user invitation flow as well as permission flow from /profile page (When user remove ORCID linkage and tries to give permissions again).
[ ] To be confirmed...
Jason-Gush
commented
2 years ago To discuss timeline and review approach, remains a problem.
Jason-Gush
commented
1 year ago Still seems to be a problem see: User 9913 and 592, first invite to vuw.ac.nz and second to auckland.ac.nz erroring: https://royal-society-of-new-zealand.sentry.io/issues/3999077825/?project=226636
nad2000
commented
1 year ago ups, it got merged into the "master" branch instead of "prod" ...
nad2000
commented
1 year ago This is something else, - https://royal-society-of-new-zealand.sentry.io/issues/3999077825/?project=226636 -it was an attempt to change the email via member view and assigned email that was already assigned to a user to a different use.
To reproduce behaviour (for a single organisation):
1/ invite user with a given address in real world usage a addresss@gmail.com This links their ORCID iD with the gmail address 2/ invite user with another address, in real world their address@institution.org.nz
When they respond to the new invite:
What should happen?
User is identified by their ORCID iD, they should be logged in and (likely for consistency) their email address updated to the address of the new invite.