Allow Completion of User Verification Workflows Without Having to be Logged In

[cholly75]

As a DAWSON user, so that I can easily complete my change email request, I need to be able to complete the verification workflow without having to still be logged into DAWSON.

One of the pain points associated with the email change workflow is that a user must complete the verification flow on the same device where they are already logged into DAWSON. This results in many support tickets with users confused and/or unable to complete the flow.

We should fix this.

Pre-Conditions

Acceptance Criteria

• User can complete change email flow including verification without having to be already logged into DAWSON on the same device as that which is being used to complete the verification.

Notes

• Security concerns? Steps to recreate the pain points:

Pain Point 1 - User is not logged in when they attempt to verify their new email.

• As a Petitioner, create a DAWSON account (or you can also be an admissions clerk and create a Practitioner account for a user)
• Once the account is created, you will receive a message that you need to verify your email
• Navigate to your email and then click on the Verify email button
• You will receive a message indicating that your email is verified and you can now log in
• Log in as the Petitioner
• Click on the person icon in the upper right corner of the page and then select My Account
• Click on the change email link
• Type in a new email (one that you still have access to) and then click save
• There will be a yellow banner at the top of the page that tells the user to verify the new email (nothing about requirements that they have to stay logged in, or be on the same browser, or on the same device)
• Next, log out of DAWSON
• Navigate to your email
• Click on the verify email button in the "Verify your new email" message that you received (this email isn't very helpful to the user, it doesn't tell them that they must be logged in, or using the same browser, and that they must be on the same device).
• New tab opens to the DAWSON login page. It will flash blue (indicating that it is updating contact information), but then a red error message displays: "Unable to complete your request" (This error message isn't very helpful to the user. It doesn't tell them that they must be logged in, or using the same browser, and that they must be on the same device).

Pain Point 2 - User is logged in to DAWSON on browser A, but they click Verify Email button from their email in browser B.

• As a Petitioner, create a DAWSON account (or you can also be an admissions clerk and create a Practitioner account for a user)
• Once the account is created, you will receive a message that you need to verify your email
• Navigate to your email and then click on the Verify email button
• You will receive a message indicating that your email is verified and you can now log in
• Log in as the Petitioner
• Click on the person icon in the upper right corner of the page and then select My Account
• Click on the change email link
• Type in a new email (one that you still have access to) and then click save
• There will be a yellow banner at the top of the page that tells the user to verify the new email (nothing about requirements that they have to stay logged in, or be on the same browser, or the same device)
• Next, access your email from a different browser (if you are using Edge for DAWSON, use Chrome (or any browser besides edge) to access your email.
• From that different browser, click on the verify email button in the "Verify your new email" message that you received.
• New tab opens to the DAWSON login page. It will flash blue (indicating that it is updating contact information), but then a red error message displays: "Unable to complete your request"

Pain Point 3 - User is logged in to DAWSON on browser A, but they click Verify Email button from their email on a different device (same browser/different device)

• As a Petitioner, create a DAWSON account (or you can also be an admissions clerk and create a Practitioner account for a user)
• Once the account is created, you will receive a message that you need to verify your email
• Navigate to your email and then click on the Verify email button
• You will receive a message indicating that your email is verified and you can now log in
• Log in as the Petitioner
• Click on the person icon in the upper right corner of the page and then select My Account
• Click on the change email link
• Type in a new email (one that you still have access to) and then click save
• There will be a yellow banner at the top of the page that tells the user to verify the new email (nothing about requirements that they have to stay logged in, or be on the same browser, or the same device)
• Next, access your email from a different device (can be the same browser). click on the verify email button in the "Verify your new email" message that you received.
• New tab opens to the DAWSON login page. It will flash blue (indicating that it is updating contact information), but then a red error message displays: "Unable to complete your request"

Here is a screen grab of the error message received:

Tasks

Test Cases

Test Cases have been added to Test Rail and are also located on this spreadsheet:

8655.xlsx

Story Definition of Ready (updated on 12/23/22)

The following criteria must be met in order for the user story to be picked up by the Flexion development team. The user story must:

• [ ] Is framed in business/user need, the value has been addressed.
• [ ] Includes acceptance criteria
• [ ] Has been refined
• [ ] Pre conditions have been satisfied.

Process: Flexion developers and designers will test if the story meets acceptance criteria and test cases in Flexion dev and staging environments (“standard testing”). If additional acceptance criteria or testing scenarios are discovered while the story is in progress, a new story should be created, added to the backlog and prioritized by the product owner.

Definition of Done (Updated 5-19-22)

Product Owner

• [ ] Acceptance criteria have been met and validated on the Court's migration environment
• [ ] Add scenario to testing document, if applicable (https://docs.google.com/spreadsheets/d/1FUHKC_YrT-PosaWD5gRVmsDzI1HS_U-8CyMIb-qX9EA/edit?usp=sharing)

UX

• [ ] Business test scenarios have been refined to meet all acceptance criteria
• [ ] Usability has been validated
• [ ] Wiki has been updated (if applicable)
• [ ] Story has been tested on a mobile device (for external users only)

Engineering

• [ ] Automated test scripts have been written, including visual tests for newly added PDFs.
• [ ] Field level and page level validation errors (front-end and server-side) integrated and functioning.
• [ ] Verify that language for docket record for internal users and external users is identical.
• [ ] New screens have been added to pa11y scripts.
• [ ] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html.
• [ ] READMEs, other appropriate docs, and swagger/APIs fully updated.
• [ ] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required).
• [ ] Interactors should validate entities before calling persistence methods.
• [ ] Code refactored for clarity and to remove any known technical debt.
• [ ] If new docket entries have been added as seed data to efcms-local.json, 3 local s3 files corresponding to that docketEntryId have been added to web-api/storage/fixtures/s3/noop-documents-local-us-east-1
• [ ] Acceptance criteria for the story has been met.
• [ ] If there are special instructions in order to deploy into the next environment, add them as a comment in the story.
• [ ] If the work completed for the story requires a reindex without a migration, or any other special deploy steps, apply these changes to the following flexion branches:
  • [ ] experimental1
  • [ ] experimental2
  • [ ] experimental3
  • [ ] experimental4
  • [ ] experimental5
  • [ ] experimental6
  • [ ] develop
• [ ] Reviewed by UX on a deployed environment.
• [ ] Reviewed by PO on a deployed environment. Can be deployed to the Court's test environment if prod-like data is required. Otherwise deployed to any experimental environment.
• [ ] Deployed to the Court's staging environment.

[katiecissell]

Pre-refinement notes:

• Should we be telling the old email that their Dawson email was changed?

[ttlenard]

@akuny

Testing feedback:

I've got a question about the implementation of this. If the user IS still logged in when they change their email and verify it, the original tab that the user was in still stays up on their computer and still has the yellow alert at the top of the screen. Is there any way that this tab can refresh so that the yellow alert is no longer displayed? This isn't a deal breaker, but implementation of this could be cleaner.

[akuny]

@ttlenard Right now, the way that "A verification email has been sent to [...]" works is that it only displays if, on page load, the user has a pending email: that's the extent of the current logic.

We can't retrigger a page load based on an external action like the user opening a link in a separate tab or browser, but it would be technically possible to periodically poll the server to reconfirm whether or not the user has a pending email. I'm not sure if this additional complexity is worth it, though.

[ttlenard]

I added the blocked label for now, as we are waiting for the IRS to test this to ensure the changes in this story do not impact their workflows.