[CST] Modifies claim letter downloader to include a new field for a unified display description

[iandonovan]

Summary

• This work is behind a feature toggle (flipper): YES
• The Claim Letter Downloader will now add a new field, called display_description, to the rendered letter json. This allows the clients (web and mobile) to display the same, human-readable name for each letter.
• I'm on BMT2.
• I am not introducing a new flipper, but in order for the additional claim letters to be rendered, we will have to enable the following two flippers:

1. cst_include_ddl_5103_letters
2. cst_include_ddl_sqd_letters

Related issue(s)

• Original change request
• Investigation
• Issue for the actions to be taken

Testing done

• New code is covered by unit tests
• The Claim Letter downloader did not include a human-readable name with each letter. As a result, the client side was responsible for showing one (if at all). For example, this is the transformation done on vets-website.
• Separate from the feature flipper, we will know my changes are working my seeing the new display_description field within the claim letter json.
• When we enable the feature flippers, we will see more claim letters rendered to the client, and these new ones will also include display_description.

What areas of the site does it impact?

This affects the Claim Letters view.

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 (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

Requested Feedback

I was looking around in the mobile app to see their analogous code to the frontend transformation linked above, but did not find any. How does mobile do this? My goal is to get the letter names standardized without the need for changing any mobile code, but I think adding a new field to the json response will necessitate accommodating changes to display that new field in the mobile app. Right?

[iandonovan]

I'm flying blind on this one, I'm not sure if this file is automated or if I need to change it or what.

[jerekshoe]

I would go ahead and call this display_name as that is used elsewhere in CST

[iandonovan]

After this conversation I am going to reappropriate the type_description, actually. That's what mobile is displaying, so I will simply change that field to be the human-readable name.

Does that sound ok to you?

[iandonovan]

This is the same mapping from the frontend, which also mirrors Julie's table in the initial change request.

[dysbo]

pretty cool to have this mapping happening in one place

[rmtolmach]

40 commits behind master. I'm updating your branch just in case.

[github-actions]

Backend-review-group approval confirmed.