Reevaluate remaining work for Signature Component: Engineering

[pacerwow]

Issue Description

As a DBEX team member, I want to know what engineering work is finished for the Signature Component feature so that the work can be resumed and executed by Engineering.

Around April of 2024 we put this work on pause in favor of putting our focus on Toxic Exposure. Where did we leave off on this work? What was done and is there any remaining engineering work to do? This ticket is simply to understand if there is any remaining engineering work.

Tasks

• [x] Research into old tickets, slack threads
• [x] Look at Figma design files for discovery
• [x] Identify if previous engineering solution is aligned with latest patterns and knowledge

Acceptance Criteria

• [x] DBEX Team 1 knows if engineering is complete or incomplete on this work
• [x] Document in the comments of this ticket what was completed and what work is remaining (if any) from a engineering perspective
• [ ] Share results with the DBEX Team 1, 2, and OCTO
• [ ] If remaining engineering work is required, those tickets are written and have the disability-benefits label. Strive to be detailed based on what is known currently, but know that these tickets will be refined.

[tommasina-va]

Previous engineering solution entailed implementing 5103 and signature component on three pages (intro, supporting evidence, and review and submit) using existing components and embedding a link:

• Alert component: Can use existing va-alert component (v3): https://design.va.gov/components/alert/
• Process list: Can use existing va-process-list component (v3): https://design.va.gov/components/process-list
• Certification/Signature: can use existing Statement of Truth component (v3): https://design.va.gov/components/form/statement-of-truth with preSubmitInfo (https://depo-platform-documentation.scrollhelp.site/developer-docs/va-forms-library-form-config-options#VAFormsLibrary-FormConfigOptions-preSubmitInfo)
• Link to specific page of PDF (or leaner alternative): If using a URL (implied by content language), we can use the page parameter in the linked url "#page=3"; Otherwise, can generate a separate PDF that only contains page 3, for example.

This still seems viable, and is accurately reflected in these two stories:

• https://github.com/department-of-veterans-affairs/va.gov-team/issues/84062 (should this be in the backlog?)
• https://github.com/department-of-veterans-affairs/va.gov-team/issues/83534
• WIP new ticket for BE work: https://github.com/orgs/department-of-veterans-affairs/projects/1268/views/10?pane=issue&itemId=84873910&issue=department-of-veterans-affairs%7Cva.gov-team%7C95941

After reviewing tickets, slack threads, and designs, I was left with these outstanding questions:

Outstanding questions:

1. [design] For all 3 pages (intro, supporting evidence and review and submit), do we plan on adding heading annotations to the mocks for the steps and alert titles? This would be super helpful to make sure we address the a11y concerns from midpoint. [From Christine]
2. [engineering] Can these two tickets be deployed independently if they're behind a environment check? In other words, does having two separate stories make sense?
3. [both] will this work hold up or impact TE 1.1 in any way? (we waited until we were through staging review for 1.0 before).

Answers to previous questions:

1. Looks like LH has a field for claimantCertification. On the BE, are we already marking this flag? It is required so assuming yes? On the FE, there is currently a field called privacyAgreementAccepted. Is it ok for us to reuse this field or do we need the ability to distinguish between the privacy agreement only vs claim certification?
   • Answer: Yes we do have claimant_certification as an attribute on the Form526 Request Body https://github.com/department-of-veterans-affairs/vets-api/blob/5dda35c4e6f4062f9e9362c3695c6cf5d518daab/lib/disability_compensation/requests/form526_request_body.rb#L319. For Lighthouse submissions, we are setting the field to true by default: https://github.com/department-of-veterans-affairs/vets-api/blob/5dda35c4e6f4062f9e9362c3695c6cf5d518daab/lib/evss/disability_compensation_form/form526_to_lighthouse_transform.rb#L86 I don’t see privacyAgreementAccepted used for any Form526 submissions on the backend. I think we should name the data claimantCertificationon the frontend and we can start dynamically capturing that in our transformation for Lighthouse.
2. For the 'Your full name' required field, do we need to do any validation on it? In terms of chars, length or comparing against anexisting field. Also, does this value need to be stored and submitted (doesn't seem like it, but just checking).
   • Answer: From Jared’s July 2 convo with OCTO, we’ll use default validations from the component which means the Input label (the text above the input field) will display the Veterans legal name on file if they enter a value that’s different. There won’t be a prefilled input field or pre-populated legal name near the Input. Since if it doesn’t match, the user won’t be able to submit, I don’t see any reason to store the value.

[tommasina-va]

1. [design] For all 3 pages (intro, supporting evidence and review and submit), do we plan on adding heading annotations to the mocks for the steps and alert titles? This would be super helpful to make sure we address the a11y concerns from midpoint. [From Christine]

Answer: It sounds like most likely yes. I will update with better answer as soon as Maya's wrapped up with the HCD review of the ticket.

2. [engineering] Can these two tickets be deployed independently if they're behind a environment check? In other words, does having two separate stories make sense?

Answer: We want to ship these together. If we really needed to, we could ship the intro page and supporting evidence page (5103) before the review and submit page (signature component). All will be behind the same environment check so it'll be either on or off.

3. [both] will this work hold up or impact TE 1.1 in any way? (we waited until we were through staging review for 1.0 before).

Answer: Might be moot if we release TE 1.1 beforehand. No real technical reason to wait. We would like to get New Confirmation Page out first. New Ongoing questions:

4. Should these links to the 5103 PDF say open in a new page?

Answer: Yes, all links should have that

5. Do we need to dynamically render the claimantCertification? Business question to be answered by OCTO stakeholders (we're not sure if there's a legal reason for it; there is no technical reason for it since submissions cannot go through without that field being marked as true.)

Kayla's answer here

6. How do we check state for Veteran's full name in a web component (for statement of truth)? Could this 4142 Statement of Truth name validation be a good pattern?

Answer: we have access to the Veterans name in props, so we're good to go here.

7. What exactly are we concerned about re: not authenticated users seeing on the intro page?

Answer: we don't want the intro page login experience to change the UI for the Veteran, so we cannot use the feature toggle. This is a good use case for the environment check.