You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
when users change their username (Sprout email address), they can no longer see their in progress CANS (until they change their email address back to the former address).
Expected behavior
Users should still have their in progress CANS associated with their new username?
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]
Smartphone (please complete the following information):
Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]
Additional context
From conversation of the issue w/ DCYF: 11/14 - This should not be happening; if a user changes their email address their in progress CANS should still be associated with/visible to the user. Ask is to Delton: how do we want to address this bug? It could be a large amount of effort to fix this bug, depending on what we decide to do about it. Impact of the issue is pretty significant, but the likelihood of it occurring may be low.
11/28 - John doesn't think it will be a common occurrence. If a sprout user changes their email (which is the same as their Sprout user name) and they are also a CANS user, when they log in with their new/different email address, CANS will provision a new user account (since it doesn't find the new email address as an existing user). This results in the users doing this losing access to their previously created CANS (under their former email address). We did follow up figure out what was going on, and fixed the issue for the users that reported the issue (manually, meaning the issue can happen again). John wants to keep record of the fix and the issue's complexity. It is a big fix, potentially (a non-trivial impact, but is likely a low use case/frequency scenario).
12/5 - this is a low priority bug we need to track, but don't need to work on urgently. Justin will mark it as closed (shared here as an FYI) and make sure the bug is logged in CSSAT's GitHub repo.
The text was updated successfully, but these errors were encountered:
Describe the bug
when users change their username (Sprout email address), they can no longer see their in progress CANS (until they change their email address back to the former address).
Expected behavior
Users should still have their in progress CANS associated with their new username?
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
From conversation of the issue w/ DCYF: 11/14 - This should not be happening; if a user changes their email address their in progress CANS should still be associated with/visible to the user. Ask is to Delton: how do we want to address this bug? It could be a large amount of effort to fix this bug, depending on what we decide to do about it. Impact of the issue is pretty significant, but the likelihood of it occurring may be low.
11/28 - John doesn't think it will be a common occurrence. If a sprout user changes their email (which is the same as their Sprout user name) and they are also a CANS user, when they log in with their new/different email address, CANS will provision a new user account (since it doesn't find the new email address as an existing user). This results in the users doing this losing access to their previously created CANS (under their former email address). We did follow up figure out what was going on, and fixed the issue for the users that reported the issue (manually, meaning the issue can happen again). John wants to keep record of the fix and the issue's complexity. It is a big fix, potentially (a non-trivial impact, but is likely a low use case/frequency scenario).
12/5 - this is a low priority bug we need to track, but don't need to work on urgently. Justin will mark it as closed (shared here as an FYI) and make sure the bug is logged in CSSAT's GitHub repo.
The text was updated successfully, but these errors were encountered: