Petition E-Mail Address Field Changes

[cholly75]

As a clerk, so that the information associated with a petitioner is clearly identifiable, I need changes made to the Petition E-Mail Address field.

The Petition E-Mail Address field was originally created to document requested e-mail service/DAWSON registration for paper petitioners and spouses. However, the labeling and values in the field can be confusing when viewed outside of the petition context post-petition/NOTR service.

We would like to make several changes to this field, including labeling, editability, and formatting.

First, we would like to rename this field on the Petitioner card to "Contact Email Address".

Sometimes a petitioner with paper service or counsel will ask us to update their email address of record as a matter of providing a way to communicate with them, regardless of whether or not they use DAWSON. In order to streamline this process, we would like to give users the ability to edit the "Contact Email Address" field when editing the Party.

Editing the value in this field is for informational purposes only and does not trigger any other behavior in DAWSON when edited.

Additionally, when a petition is electronically filed by a petitioner we would like to auto-populate the filing petitioner's "Contact Email Address" field with the same email address as their DAWSON user email (already displayed on the petitioner card).

Petitions e-filed by a practitioner already populate the petitioner's provided email address in this field during the Petitions QC process.

Pre-Conditions

Acceptance Criteria

• "Petition email address" field on the Parties/Petitioner card is relabeled as "Contact Email Address"
• Petition QC screen "Petition email address" field is relabeled as "Contact Email Address:" (no bolding)
• When editing a Petitioner party, the Edit Party screen has a new "Contact Email Address (optional)" field added below the phone number field and this field is editable
• Petitioner e-filed Petitions: Petitions QC screen autopopulates the "Contact Email Address" field with the DAWSON username of the filer
• No changes to visibility of the "Contact Email Address" field

Notes

• No need to go back to previous cases to autopopulate the Contact Email Address field with the DAWSON username of the eFiler. This will just be going forward when this story is deployed.

Tasks

Test Cases

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]

UX Notes:

Figma File

Petitioner info update:
Add a label to service email as well as updating petition email address to contact email address

Petition QC update:

For editing party info, add a contact email address field.

[ttlenard]

Test Cases

1) Internal Court user views the Party tab of a case; The "Petition email address" header is renamed to "Contact email address" and the Email address field is renamed to "Service email address".

• Log in as a Court user
• Navigate to a Case
• Click on the Case Information tab
• Click on the Parties tab
• Review the Petitioner cards

Expected Results:

• NEW FUNCTIONALITY - The Petition Email Address header is now displayed as "Contact email address"
• NEW FUNCTIONALITY - The Email Address header is now displayed as "Service email address"

*Be sure to check a number of cases (cases with/without service emails and with/without contact email addresses") to ensure that it is displayed appropriately.

*Repeat this test with all the Court user roles

2) External Party views the Party tab of a case; no changes to the existing look of the card (no contact email address field displayed for external parties).

• Log in as a Petitioner
• Navigate to a case that you have access to
• Click on the Case Information tab
• Click on the Parties Tab
• Review the Petitioner Cards

Expected Results

• No change to the existing Petitioner cards (no "Contact email address" header is displayed)

*Repeat this test with Private Practitioner and IRS Practitioner (when testing with an IRS Practitioner, access a case that you are a party to, and one that you aren't a party to. The petitioner card should look the same)

3) Petitions Clerk QC's a paper filed petition, Petition email address field is renamed to "Contact email address".

• Log in as a Petitions Clerk
• Click on the Document QC Tab
• Click Start a Petition button
• Select a party type
• Review the email address underneath the State/ZIP fields

Expected Results:

• NEW FUNCTIONALITY - The Petition email address field has been renamed to "Contact email address (optional)"
• The data field functions the same - no change to validation, it is still an optional field.
• NEW FUNCTIONALITY - This field has been renamed for ALL Party types in the dropdown, including for both Petitioner and Spouse if Petitioner and Spouse is selected.
• NEW FUNCTIONALITY - After service to the IRS when you view the Party tab, the Service email address and Contact email address headers display appropriately on the Party card.

*Repeat this test with CSS role

4) Petitioner eFiles a petition for petitioner and Spouse case - Email address field for Spouse displays as per normal and is not changed.

• Log in as a Petitioner
• Click Create a Case
• Select the party type of Petitioner and Spouse
• Review the Email Address Field for the Spouse

Expected Results:

• The email address field displays as "Email Address (Optional)" as per normal
• NEW FUNCTIONALITY - After submitting the case, and viewing the party tab, there is now a header that states, "Service Email Address" over the service email section (It will display "No email provided" under this header as per normal for Spouse).

5) Practitioner eFiles a petition for petitioner and Spouse case - Email address field for Petitioner and Spouse displays as per normal and is not changed.

• Log in as a Practitioner
• Click Create a Case
• Select a party type
• Review the Email Address Field

Expected Results:

• The email address field displays as "Email Address (Optional)" as per normal
• NEW FUNCTIONALITY - After submitting the case, and viewing the party tab, there is now a header that states, "Service Email Address" over the service email section (It will display "No email provided" under this header as per normal for Petitioner).

*Repeat this test with all of the party types. Email address should continue to display "Email Address" as per normal. No changes to this display.

6) Petitions Clerk QC's an eFiled petition; New field on the Petition QC Page for Contact email address, which is auto-populated with the petitioners DAWSON username (email).

• Continuing from the previous test
• Click on Document QC
• Click on Section Document QC
• Click on the Petition link for a Petition (Not a Petitioner and Spouse case)
• Review the Petition Page

Expected Results:

• NEW FUNCTIONALITY - There is a new Contact email address (optional) field displayed underneath the State/ZIP Code fields
• There is NOT an eService consent checkbox for the eFiler.
• NEW FUNCTIONALITY - This field is auto-populated with the users DAWSON Username (email) only if this petition was eFiled AFTER the deployment of this story. If this petition was submitted prior to deployment of this story, then the username is NOT auto-populated (we're not doing a migration), but the field should be present.

*Repeat this test with all of the Party types (Corporation, Partnership representative, Trust, etc.). For each party type, the contact email address field is auto-populated.

*Repeat this test with CSS Role

7) Petitions Clerk QC's an eFiled petition (Petitioner and Spouse); New field on the Petition QC Page for Contact email address, which is auto-populated with petitioner 1's DAWSON username (email), Contact email address field is now displayed for Spouse.

• Continuing from the previous test
• Click on Document QC
• Click on Section Document QC
• Click on the Petition link for a Petitioner and Spouse case
• Review the Petition Page

Expected Results:

• NEW FUNCTIONALITY - There is a new Contact email address (optional) field displayed underneath the State/ZIP Code fields for Petitioner 1
• There is NOT an eService consent checkbox for the first Petitioner.
• NEW FUNCTIONALITY - This field for the first petitioner is auto-populated with the users DAWSON Username (email) only if this petition was eFiled AFTER the deployment of this story. If this petition was submitted prior to deployment of this story, then the username is NOT auto-populated (we're not doing a migration), but the field should be present.
• NEW FUNCTIONALITY - There is a new Contact email address (optional) field displayed underneath the State/ZIP Code fields for Petitioner 2/Spouse
• There is NOT an eService consent checkbox for the Spouse that is displayed
• NEW FUNCTIONALITY - The Contact email address is displaying whatever the Petitioner had input (check this by eFiling as a Petitioner to ensure data is displayed correctly)

*Repeat this with CSS role

8) Docket Clerk edits a petitioner's contact information, Contact Email address field now displays and is editable.

• Log in as a Docket Clerk
• Navigate to a case
• Click on the Case information tab
• Select the parties tab
• Click the Edit link next to a Petitioner

Expected Results:

• NEW FUNCTIONALITY - There is now the "Contact email address (Optional)" field displayed on the Edit screen
• NEW FUNCTIONALITY - If there was an email address added for "Petition email address", then this email is displayed
• If there was eService Consent checked (or not), it is NEVER displayed appropriately to the clerk
• NEW FUNCTIONALITY - Clerk can edit the data in the Contact Email address field, data saves appropriately.
• NEW FUNCTIONALITY - No Notice of Change of contact information is generated when the contact email address field is edited
• NEW FUNCTIONALITY - Contact email address field on the edit petitioner contact info screen has the same validation as it does during the petition QC workflow (email must be in a valid format).

*Repeat this test with a CSS and Clerk of the Court Role

9) Docket Clerk seals a Petitioner's address; the Petitioner also has a Contact email address listed; Address info seals as per normal, including the Contact Email address.

• This is a regression test
• Log in as a docket clerk
• Navigate to a case that has a Petitioner with a contact email address
• Click on the Edit link next to the petitioner
• Seal the address
• Click Save

Expected Results:

• Contact email address is sealed as per normal
• Contact email address can only be viewed by some of the roles (CSS, Clerk of the Court, Docket, Admissions) as per normal

*Repeat this test with CSS and CotC roles

10) Petitioner edits their contact information on a case; Contact email address field does not display for the Petitioner.

• This is a Regression Test
• Log in as a Petitioner
• Navigate to one of your cases
• Click on the Case information and then Parties tab
• Click on Edit
• Review the edit Contact Information screen

Expected Results:

• No Contact email address field is displayed for the Petitioner to edit

11) Practitioner edits the contact information for a Petitioner on a case; Contact email address field does not display for the Practitioner.

• This is a Regression Test
• Log in as a Practitioner
• Navigate to one of your cases
• Click on the Case information and then Parties tab
• Click on Edit for a petitioner on the case
• Review the edit Contact Information screen

Expected Results:

• No Contact email address field is displayed for the Petitioner

12) Petitioner that eFiled a petition and their contact email address was auto-populated with their service email address changes their email address; Contact email address remains as the original email that they used, and their Service email address is updated.

• Log in as a Petitioner
• Submit a Petition
• Log in as a Petitions Clerk and navigate to the case that was just submitted
• As a Petitions clerk, notice that the users Service email address will be the same as their Contact Email address
• Serve the Petition
• Next, after the Petition is served to the IRS, log back in as the petitioner
• Click on my account
• Update your email address
• Verify the email address
• Next, log in as any Court user
• Navigate to the same case and click on the Case info/Parties Tab
• Review the Petitioner information

Expected Results:

• The Contact email address field is the original email address for the Petitioner
• The Service email address is the new email address for the Petitioner

13) Docket Clerk edits Petitioner contact info on an older case where there is no previous Contact email address; Adds a contact email address; Data saves appropriately, no notice of change of contact information generated.

Part 1

• Log in as a docket clerk
• Navigate to an older case where there is no contact email address for a petitioner
• Click on the edit link to edit the Petitioner contact data

Expected Results:

• NEW FUNCTIONALITY - There is a Contact email address field

Part 2

• Add in a contact email address
• Click save

Expected Results

• NEW FUNCTIONALITY - New contact email address field is saved appropriately
• No Notice of Change generated
• NEW FUNCTIONALITY - Newly added Contact email address field is displayed on the Petitioner contact card for internal users.

*Test this with CotC, CSS roles

14) Review the JSON to ensure that the contact email address is being displayed/not being displayed appropriately.

• All Court users can view the case json and see the contact email address as long as it is not sealed
• Only Docket, Admissions, CotC, and CSS can see the sealed contact email addresses (and other sealed address info) in the JSON
• External parties cannot see the contact email address field of parties (probably shouldn't see the "hasConsentedToEService" , isAddressSealed" either. Also maybe not the "contactId"? I think this one is very specific to the scenario
• External users not associated with a case cannot see the contact email address