New endpoints for 21-22/21-22a PDF generation

[oddball-lindsay]

Background

When a user clicks "download" on the frontend (at the end of the Appoint a Representative experience), the backend will need to receive all of the form information from the frontend to build the PDF.

Open questions to explore:

1. How is the PDF accessed by the frontend?
2. Is there a file stored in the backend? Thinking no, as there are PII concerns.

Update (6/24/24):

• Swagger docs will come in a follow-on ticket.
• Full controller and model tests will come in a follow-on ticket.

Tasks

• [x] Background knowledge on swagger docs (swagger documentation to come in
• [x] Create the endpoints, one each for 21-22 and 21-22a
• [x] Add test for 200/okay happy path
• [x] Add simple test for 422/unprocessable_entity unhappy path

Acceptance Criteria

• [x] An endpoint for generating a PDF is created with basic tests

[oddball-lindsay]

Something to consider for the frontend form config, as the Appoint experience covers two forms (21-22 and 21-22a) - can we lean on a universal endpoint, or do we need a separate endpoint for each form?

Leaning towards two separate endpoints for PDF generation.

[opticbob]

In process thoughts/questions:

• The 21-22 schema doesn't seem to match up perfectly with the form. The schema requires a POA code for example, which isn't present on the form. The form has a place for a name of a representative within a VSO and that isn't present in the schema. Is this an issue?
• Where does validation logic typically live? Will users be able to submit these forms with incomplete information so they can write it in before sending it in? Will the frontend allow submitting the form with incomplete information?
• Depending on the answer to the above question we may need logic to account for required/non required params. Non required params include things like the second line of addresses, phone number extensions, and zip code suffixes. If there is no claimant those fields aren't required.
• V0::CaregiversAssistanceClaimsController#download_pdf is a good example of a PDF being filled in on the fly within a request and immediately serving it up to the user.

[oddball-lindsay]

@opticbob I don't know enough to directly answer your questions, but here's some information that may help:

• When defining the Lighthouse service for submitting a 21-22/21-22a, we determined these to be the required form fields. The frontend experience should be reinforcing these required fields.
• Have you seen these API docs for the Benefits Claims API? The relevant ones for us are at the bottom -- the "Power of Attorney" section and there is a /validate for each form.
• Lighthouse's Benefits Claims API is operating on an older version of the 21-22/21-22a, since the form was updated after the Lighthouse work began. We're operating in an interesting space where ARM needs to serve up the most-recent version of the forms when generating the PDF, but send Lighthouse the information they're expecting based on an older version of the form.

[oddball-lindsay]

Working through some pre-review comments from Holden, hoping to wrap up soon.

[oddball-lindsay]

21-22 app code is complete, finishing up 21-22a then looking for review.