Admissions clerk adds email to Petitioner without Existing Cognito Account

[mariahkannenberg]

As an admissions clerk, so that I can give a petitioner access to the system, I need the ability to give electronic access to a petitioner who does not have an existing Cognito account

Pre-Conditions

7658

Acceptance Criteria

• When Admissions Clerk adds an email address, a new cognito account is created
• When a new Cognito account is created, the petitioner receives an email to verify their account
• Pending email displays for petitioner

Mobile Design/Considerations

Security Considerations

• [ ] Does this work make you nervous about privacy or security?
• [x] Does this work make major changes to the system?
• [ ] Does this work implement new authentication or security controls?
• [ ] Does this work create new methods of authentication, modify existing security controls, or explicitly implement any security or privacy features?

Notes

Tasks

• [x] Create no matching email modal (Tech Mob #7828)
  • [x] Display “No Matching Service Email" modal (Tech Mob #7828)
  • [x] Display associated Petitioner Name (Tech Mob #7828)
  • [x] Display email (Tech Mob #7828)
• [x] On click of Yes in the modal, Continue
  • [x] Modal closes and app routes to Case Detail> Petitioner with success message displayed - Team mob
  • [x] Pending email is displayed under the associated petitioner - Team mob #7861
  • [x] Cognito account is created (Tech Mob) - #7853
  • [x] Email receives new account verification email - #7853
  • [x] Service indicator remains paper
  • [x] Email does not receive service emails
• [x] When email is added but not verified on Edit Petitioner Information page
  • [x] Display Service preference = Paper
  • [x] Display “Pending Email address” field and hide email form
  • [x] Display warning alert under Service Info

Definition of Done (Updated 2-23-21)

Product Owner

• [x] Acceptance criteria have been met and validated on the Flexion Prod env

UX

• [x] Business test scenarios to meet all acceptance criteria have been written
• [x] Usability has been validated
• [x] Wiki has been updated (if applicable)
• [ ] Story has been tested on a mobile device (for external users only)
• [x] Add scenario to testing document, if applicable (https://docs.google.com/spreadsheets/d/1FUHKC_YrT-PosaWD5gRVmsDzI1HS_U-8CyMIb-qX9EA/edit?usp=sharing)

Engineering

• [x] Automated test scripts have been written
• [x] Field level and page level validation errors (front-end and server-side) integrated and functioning
• [x] Verify that language for docket record for internal users and external users is identical
• [x] New screens have been added to pa11y scripts
• [x] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html
• [x] READMEs, other appropriate docs, JSDocs and swagger/APIs fully updated
• [x] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required)
• [x] Module dependencies are up-to-date and are at the latest resolvable version (npm update)
• [x] Errors in Sonarcloud are fixed https://sonarcloud.io/organizations/flexion-github/projects
• [x] Lambdas include CloudWatch logging of users, inputs and outputs
• [x] Interactors should validate entities before calling persistence methods
• [x] Code refactored for clarity and to remove any known technical debt
• [x] Rebuild entity documentation
• [x] Acceptance criteria for the story has been met
• [x] Deployed to the dev environment

• [ ] Deployed to the Court's migration environment

  Review Steps

  1. Finish all other DOD
  2. Deploy to the dev environment
  3. Engineers add Needs UX Review label
  4. UX Review on dev environment (if feedback, implement and go back to step 2)
  5. UX add Needs Migration Deploy label
  6. Deploy to the Court's migration environment
  7. Engineers go through test scenarios on Court's migration environment
  8. Engineers add Needs PO Review label and move to Review/QA column
  9. PO review (if feedback, implement and go back to step 2)

[klohman]

No Email Exists

When email is added and no matching email exists:

• Display “No Matching Service Email" modal
• Display associated Petitioner Name
• Display email

On click of Yes, Continue

• Modal closes and app routes to Case Detail> Petitioner with success message displayed
• Pending email is displayed under the associated petitioner
• Cognito account is created
• Email receives new account verification email
• Service indicator remains paper
• Email does not receive service emails

Case Detail > Petitioner - Pending email

When email is added but not verified

• Display Service preference = Paper
• Display “Pending Email address” field

Edit Petitioner Information - Pending email

When email is added but not verified

• Display alert under Service Info

Service preference options include:

• Paper

• None

• Display Pending email address

New email account

• The email receives the new account email from Cognito

[klohman]

7806 Test Scenarios

1) Admissions clerk adds service email that is not in the system to petitioner on case (primary contact)

• Login as admissions clerk
• Go to case xx3-20
  • Case has party type = Petitioner & Spouse
  • Petitioner & Spouse have no email and paper service
• Click Case Information > Petitioner
• Click edit link for primary contact
• Enter and re-enter new email = [new email]
  • Dev - flexionustc+newemail@gmail.com
• Click Save
• Click Yes, Continue Expected results On Save:
• [x] Confirm No Matching Email Found modal displays
• [x] Email displays in modal
• [x] petitioner name displays in modal On Click of Yes, Continue
• [x] Modal closes and app routes to Case Information > Petitioner tab with success message displayed
• [x] Petitioner service indicator remains Paper
• [x] Email displays under Petitioner Card as Pending email address
• [x] New email receives Cognito welcome email

2) Internal user sees pending email when new service email is unverified for petitioner (primary contact) on Petitioner info card

• Scenario 1
• Login as petitions clerk
• Go to case xx3-20
• Click Case Information > Petitioner Expected results
• [x] Petitioner service indicator remains Paper
• [x] Email displays under Petitioner Card as Pending email address

3) Admission clerk/Docket clerk sees pending email when new service email is unverified for petitioner (primary contact) on Edit Petitioner Info screen

• Scenario 1
• Login as admission clerk / docket clerk
• Go to case xx3-20
• Click Case Information > Petitioner
• Click Edit link for primary contact Expected results
• [x] Primary contact service indicator displays as Paper
• [x] electronic service option is hidden
• [x] Pending email warning alert displays
• [x] Pending email field displays read-only

4) Admissions clerk adds email to case and petitioner (primary contact) receives paper service for party-filed document before the email is verified

• Scenario 1
• Login as docket clerk
• Go to case xx3-20
• Add Paper Filing
• Complete Form
• Save and Serve Expected results
• [x] Modal displays indicating that primary contact receives paper service
• [x] App routes to Print Paper Service screen
• [x] Pending email does not receive service email

5) Admissions clerk adds email to case and petitioner (primary contact) receives paper service for court-issued document before email is verified

• Scenario 1
• Login as docket clerk
• Go to case xx3-20
• Create, sign, and save Order
• Add Docket entry for Order
• Save and Serve Expected results
• [x] Modal displays indicating that primary contact receives paper service
• [x] App routes to Print Paper Service screen
• [x] Pending email does not receive service email