Issue 416: [Frontend] Add a download button to the Data Files view

[riatzukiza]

Summary of Changes

_Addresses issue #416

Adds a file download button to each file the backend lists as having a file available. Currently the backend is mocked
through mirage. A new pr will have to be issued which connects the button logic to the backend when the endpoints are implemented.

How to Test

1. Login to app
2. Navigate to file upload page
3. select a year
4. press download

Deliverable 1: Accepted Features

Performance Standard(s): At the beginning of each sprint, the Product Owner and development team will collaborate to define a set of user stories to be completed during the sprint. Acceptance criteria for each story will also be defined. The development team will deliver code and functionality to satisfy these user stories.

Acceptable Quality Level: Delivered code meets the acceptance criteria for each user story. Incomplete stories will be assessed and considered for inclusion in the next sprint.

• Download Buttons are added to the page
• Clicking on Download downloads the correct section
• Frontend matches delivered and accepted mockup (link to figma below)
• All tests are passing
• Test coverage exceeds 90%

As facilitator/product manager, @kniz-raft will decide if ACs are met from Raft's perspective.

Deliverable 2: Tested Code

Performance Standard(s): Code delivered under the order must have substantial test code coverage. Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality Level: Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: ___ (see https://github.com/raft-tech/TANF-app README coverage dashboard)
  • Backend coverage: ___ (see https://github.com/raft-tech/TANF-app README coverage dashboard)

Deliverable 3: Properly Styled Code

Performance Standard(s): GSA 18F Front- End Guide

Acceptable Quality Level: 0 linting errors and 0 warnings

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Does this PR change any linting or CI settings?

Deliverable 4: Accessible

Performance Standard(s): Web Content Accessibility Guidelines 2.1 AA standards

Acceptable Quality Level: 0 errors reported using an automated scanner and 0 errors reported in manual testing

• Did automated and manual testing with @iamjolly and @ttran-hub using Accessibility Insights reveal any errors introduced in this PR?
  • See the full Accessibility Assessment plan here.

Deliverable 5: Deployed

Performance Standard(s): Code must successfully build and deploy into the staging environment.

Acceptable Quality Level: Successful build with a single command

NOTE: until we have a proper staging environment this may not be satisfiable prior to merging

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

Performance Standard(s): Summary of user stories completed every two weeks. All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented, including system diagram. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. All non-inherited 800-53 system security controls are documented in the Open Control or OSCAL format and HHS Section 508 Product Assessment Template (PAT) are updated as appropriate.

Acceptable Quality Level: Combination of manual review and automated testing, if available

• If this PR introduces backend code, is that code documented both inline and overall?
• If this PR introduces frontend code, is that code documented both inline and overall?
• If this PR introduces dependencies, are their licenses documented?

Deliverable 7: Secure

Performance Standard(s): Open Web Application Security Project (OWASP) Application Security Verification Standard 3.0

Acceptable Quality Level: Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?

[reitermb]

Raft a11y review:
cc: @ADPennington

Button behavior & markup are looking good! Button copy needs to be adjusted for a11y & mockup compliance though. Buttons and their accessible labels currently all read as "Download". They should follow the "Download Section [Section#]" format as documented in #416 and mockups.

Adjusting the button class to use usa-button usa-button--outline would also be ideal to maintain a sense of visual hierarchy between primary and secondary buttons.

[ADPennington]

i like that we're using the report file metadata in the filename of the downloaded file because STTs will (at least for now) probably maintain those standard naming conventions, and this makes it easer to distinguish them. A couple of thoughts for possible future enhancements:

• may be worth asking STT users in a future workshop if the download file names are recognizable or if they have any preference for including the original filename in the name
• I'd like to see year prefixed with "FY" (fiscal year) so its crystal clear that this is different from calendar year (something STTs have expressed confusion on), but this is another thing that would be good for STT users to react to now that the feature is here 😄
  cc: @dk-ui

[ADPennington]

looking good @riatzukiza had a few in-line questions re:

• when the button appears
• feasibility of getting the button label aligned with figma mockups since this is an AC.

[reitermb]

Button a11y/ac is looking good now as per the copy change!

[ADPennington]

looking good @riatzukiza had a few in-line questions re:

• when the button appears
• feasibility of getting the button label aligned with figma mockups since this is an AC.

Thanks for the download button label @riatzukiza ! also capturing discussion from 7/7 dev sync:

• currently button appears at the point of upload but this is temporary until [Frontend] Hook upload and download to real API endpoints #834 is addressed.
• current vision is for download button to be presented if file previously submitted. It will trigger download of most recent submission.
• longer term research and planning needed to understand if STTs need the ability to retrieve multiple versions of data submitted

[ADPennington]

@abottoms-coder this is ready to merge. thanks @riatzukiza!

Deliverable 1: Accepted Features

Performance Standard(s): At the beginning of each sprint, the Product Owner and development team will collaborate to define a set of user stories to be completed during the sprint. Acceptance criteria for each story will also be defined. The development team will deliver code and functionality to satisfy these user stories.

Acceptable Quality Level: Delivered code meets the acceptance criteria for each user story. Incomplete stories will be assessed and considered for inclusion in the next sprint.

• Look up the acceptance criteria in the related issue; paste ACs below in checklist format.
• Check against the criteria:
  • Download Buttons are added to the page
  • Clicking on Download downloads the correct section
  • Frontend matches delivered and accepted mockup (link to figma below)

Test coverage exceeds 90%

As Product Owner, @lfrohlich will decide if ACs are met.

Deliverable 2: Tested Code

Performance Standard(s): Code delivered under the order must have substantial test code coverage. Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality Level: Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: ___ (see https://github.com/raft-tech/TANF-app README coverage dashboard)

Deliverable 3: Properly Styled Code

Performance Standard(s): GSA 18F Front- End Guide

Acceptable Quality Level: 0 linting errors and 0 warnings

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?

Deliverable 4: Accessible

Performance Standard(s): Web Content Accessibility Guidelines 2.1 AA standards

Acceptable Quality Level: 0 errors reported using an automated scanner and 0 errors reported in manual testing

• Does this PR complete the epic?
  no: this work is associated with As an OFA admin, I can download raw file #89 and will be completed when [Frontend] Hook upload and download to real API endpoints #834 work is addressed
• Are links included to any other gov-approved PRs associated with epic?
  links: [A11y] Upload functionality improvements #858
• Does PR include documentation for Raft's a11y review?
  here and here

Deliverable 5: Deployed

Performance Standard(s): Code must successfully build and deploy into the staging environment.

Acceptable Quality Level: Successful build with a single command

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

Performance Standard(s): Summary of user stories completed every two weeks. All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented, including system diagram. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. All non-inherited 800-53 system security controls are documented in the Open Control or OSCAL format and HHS Section 508 Product Assessment Template (PAT) are updated as appropriate.

Acceptable Quality Level: Combination of manual review and automated testing, if available

• If this PR introduces frontend code, is that code documented both inline and overall?

Deliverable 7: Secure

Performance Standard(s): Open Web Application Security Project (OWASP) Application Security Verification Standard 3.0

Acceptable Quality Level: Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?
  no new issues detected