[Document Upload Failure] List veteran-supplied documents in Form 526 Overflow Text

[NB28VT]

Summary

Appends a list of Veteran-attached file names to the optional overflowText field in the Form 526 metadata that gets submitted to EVSS, with a note that looks like:

'The veteran uploaded X documents along with this claim. '
"Please verify in VBMS eFolder'
-- filenames list

Also adds a note if a Form 0781/a is present.

The overflowTextfield is used to append additional notes to the Form 526 PDF for the Claim Adjudicator to review; in this case we are listing all of the files the Veteran attached to the claim so the adjudicator can cross reference them with the files that get uploaded to the veteran's eFolder to the support the claim.

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

The purpose of this change is to assist in solving the problem of VA.gov failing to upload some documents to EVSS, and that being a silent failure neither the veteran or the claim adjudicator know about. We're solving this in two ways:

1. A mailer that gets sent to the veteran for each document that fails, which obscures the filename for PII protection (e.g. "N*****B*****26.pdf"). The veteran can hopefully use that information to find the document that failed to upload and physically mail it to the VA.
2. The change in this PR that lists all the files the veteran attached, so the claim adjudicator can make sure they made it to the eFolder. Additionally, if the veteran receieved a failed upload email and doesn't recognize the obscured filename, they can work with the claim adjudicator, who sees the full filename, to determine which document they need to submit manually.

Because veterans occasionally (albeit very rarely) upload a large number of files to support their claim (400+), we don't want to always display a full file list. To summarize the spec we landed on for this:

• Ask EVSS to increase the maximum allowed size of the overflowText field to 4000 characters (from the current 1000)
• Always include the 'The veteran uploaded X documents along with this claim.' note regardless of the number of files.
• Calculate the total number of characters in all notes included in the overflowText, including the 'The veteran uploaded X documents along with this claim.' note.
• If all of the characters in the note + the full file list would exceed the 4000 character limit, do not display the full file list.

NOTE: it is likely more notes will be added to the overflowText in the near future, but we feel we have still allowed enough room for a reasonable file list

• This work is behind a feature toggle (flipper): YES A flipper named form526_include_document_upload_list_in_overflow_text is used to gate this behavior.

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

I am on the Disability Benefits team

• (If introducing a flipper, what is the success criteria being targeted?)

This will need to get tested in staging.

Still In Progress/TBD

• [X] Tweak the filename cutoff count based on historical data (i.e. what is a likely large count of files we can expect that's not abusrdly large like 600)
• [X] Get EVSS to increase the max character count in the overflowText field based on the filename cutoff
• [X] Handle character counts that exceed the overflowText max we end up with in EVSS. Truncate the file list? Need to ask OCTO about this.

Related issue(s)

• https://github.com/department-of-veterans-affairs/va.gov-team/issues/79485

Testing done

This will have its own testing plan TBD

Acceptance criteria

• [ ] I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• [ ] No error nor warning in the console.
• [ ] Events are being sent to the appropriate logging solution
• [ ] Documentation has been updated (link to documentation)
• [ ] No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• [ ] Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• [ ] If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• [ ] I added a screenshot of the developed feature

[va-vsp-bot]

Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/models/saved_claim/disability_compensation.rb

[va-vsp-bot]

Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/models/saved_claim/disability_compensation.rb

[github-actions[bot]]

1 Warning

:warning:

This PR changes 398 LoC (not counting whitespace/newlines). In order to ensure each PR receives the proper attention it deserves, we recommend not exceeding 200. Expect some delays getting reviews. File Summary Files .github/CODEOWNERS (+1/-0) app/models/saved_claim/disability_compensation.rb (+1/-1) app/models/supporting_evidence_attachment.rb (+5/-1) config/features.yml (+3/-0) lib/evss/disability_compensation_form/data_translation_all_claim.rb (+51/-2) spec/lib/evss/disability_compensation_form/data_translation_all_claim_spec.rb (+332/-1) Note: We exclude files matching the following when considering PR size: *.csv, *.json, *.tsv, *.txt, Gemfile.lock, app/swagger, modules/mobile/docs, spec/fixtures/, spec/support/vcr_cassettes/, modules/mobile/spec/support/vcr_cassettes/, db/seeds, modules/vaos/app/docs, modules/meb_api/app/docs, modules/appeals_api/app/swagger/, *.bru Big PRs are difficult to review, often become stale, and cause delays.

Generated by :no_entry_sign: Danger

[NB28VT]

1 Warning ⚠️ This PR changes 399 LoC (not counting whitespace/newlines). In order to ensure each PR receives the proper attention it deserves, we recommend not exceeding 200. Expect some delays getting reviews.

File Summary Big PRs are difficult to review, often become stale, and cause delays.

Generated by 🚫 Danger

This is always a valid concern but in this case I think it's important to have this behavior covered by extensive unit tests. One way to shrink this PR would be to separate out the logging and StatsD implementation, but I think it makes more sense to have it reviewed at the same time, as not logging the behavior might not be enough to properly release this.

[NB28VT]

For the platform reviewer: the outstanding change request by @SamStuckey has been addressed but he is out so won't be able to approve FYI