DBEX 0781 consent page

[ajones446]

Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

If the folder you changed contains a manifest.json, search for its entryName in the content-build registry.json (the entryName there will match).

If an entry for this folder exists in content-build and you are:

1. Deleting a folder:

   1. First search vets-website for all instances of the entryName in your manifest.json and remove them in a separate PR. Look particularly for references in src/applications/static-pages/static-pages-entry.js and src/platform/forms/constants.js. If you do not do this, other applications will break!
      • Add the link to your merged vets-website PR here
   2. Then, Delete the application entry in registry.json and merge that PR before this one
      • Add the link to your merged content-build PR here

2. Renaming or moving a folder: Update the entry in the registry.json, but do not merge it until your vets-website changes here are merged. The content-build PR must be merged immediately after your vets-website change is merged in to avoid CI errors with content-build (and Tugboat).

⚠️ TeamSites ⚠️

Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the #sitewide-public-websites Slack channel for questions.

Did you change site-wide styles, platform utilities or other infrastructure?

• No
• Yes, and I used the proxy-rewrite steps to test the injected header scenario

Summary

• (Summarize the changes that have been made to the platform)

  • This change adds to the chapter three conclusion flow of the new digitized 0781 flow
    • Skeleton and content for the consent page
      • NOTE: The consent page is only presented to users who selected “Traumatic events related to sexual assault or harassment (also known as military sexual trauma or MST)” as an event types in [3.6] Event type
    • Placeholder for the additional information page

• (If bug, how to reproduce)

  • n/a

• (What is the solution, why is this the solution)

  • Create a new flow and pages to align the digital form with the VA Form 21-0781 paper version

• (Which team do you work for, does your team own the maintenance of this component?)

  • Disability Benefits Experience Team 2 (dBeX Carbs 🥖), which owns maintenance of all files in this PR

• (If using a flipper, what is the end date of the flipper being required/success criteria being targeted)

  • sync_modern_0781_flow will be utilized for specific users until all who start a new form and claim a new disability will be routed through an alternative 0781 flow

Related issue(s)

• Link to ticket created in va.gov-team repo
  Consent Page Skeleton [0781 PS] (8) Consent Page Skeleton va.gov-team#97084
  Consent Page Content [0781 PS] (9) Consent Page Content va.gov-team#97871

Testing done

• Describe what the old behavior was prior to the change
  N/A - This is a new step in the digital form
• Describe the steps required to verify your changes are working as expected

1. in the development environment, ensure that the sync_modern_0781_flow toggle is enabled
2. start a new claim
3. claim at least 1 new condition
4. select at least 1 of the new conditions on the 0781 screener page
5. click through to "Types of traumatic events" page
6. confirm that the consent page is only presented to users after selecting MST

• Describe the tests completed and the results
  • unit tests added
  • tested manually

Screenshots

Note: This field is mandatory for UI changes (non-component work should NOT have screenshots).

What areas of the site does it impact?

• 526 EZ (within a new "Additional Forms" chapter)

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed
  • 0 issues found during dev axe tool scan

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

Requested Feedback

(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[freeheeling]

Some minor suggestions to consider, otherwise looks great.

[freeheeling]

Previously overlooked that optional chaining should be added here to avoid throwing a TypeError, in the event a property is null or undefined.