Issue 429: Add component to input single file

[jorgegonzalez]

Summary of Changes

• Added UploadReport component to Upload page
  • Added 4 required UploadFile sections
• Added redux actions and reducers and modeled File Upload states
• Added error handling for uploads of invalid file types
• Added placeholder 'Submit Files' button for uploads

Addresses issue #429
Acceptance criteria as stated in the issue

How to Test

1. Log in as any user.
2. Click the Reports tab.
3. Select a year in the Fiscal Year dropdown.
4. Click Search.
5. Ensure a new UploadReport section appears below the Begin Report Search button with the four required sections on the page.
6. Drag a text file (.txt file extension) to any of the four sections.
7. Check that there were no errors, and the input area changes to display a file icon with the name of the uploaded file.
8. Try the same with a non-.txt file, and check that an error message is shown
9. Clicking Submit Files should just refresh the page.
10. Clicking Cancel or changing the selected year should remove the UploadReport form.

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:
  • Files Input accepts a single file
  • Input accepts only -.txt file types
  • Upload button is a placeholder
  • Input displays a helpful error message when a wrong file type is uploaded
  • Frontend matches [Design] As a test user, I want to see dev-ready mockups to upload each section of a TANF report #427 delivered and accepted mockup
  • Testing Checklist has been run and all tests pass

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 frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: 99% (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

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

Accessibility issues have been addressed

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 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 security issues detected

[jorgegonzalez]

Updated this PR based on the latest TDP mockups; I will move this PR out of draft mode when I fix the tests.

[carltonsmith]

@jorgegonzalez Bringing this up locally I see that Data Files still shows up as Reports. As we want this to match the prototype I think we should make that change here.

[jorgegonzalez]

@jorgegonzalez Bringing this up locally I see that Data Files still shows up as Reports. As we want this to match the prototype I think we should make that change here.

This should be addressed.

[jorgegonzalez]

The AC's for this issue explicitly state that we want to accept only .txt files, so I think it would make sense to create a new issue for it or add it to the ACs for the issue mentioned above or to 430, since that's where the actual upload happens.

#430 has been updated with this requirement.

[alexsoble]

Thanks very much for making that update @jorgegonzalez!

[iamjolly]

This is really helpful info. Thanks @jorgegonzalez

[iamjolly]

This looks great from an accessibility perspective. It's good to go!

[lfrohlich]

This looks really good! One thing I noticed, that I assume will be addressed in #430 is that I could add a JPG to the component through the dialog box.

[jorgegonzalez]

This looks really good! One thing I noticed, that I assume will be addressed in #430 is that I could add a JPG to the component through the dialog box.

@lfrohlich that's correct. We added an AC to #430 to address the file type validation.

[alexsoble]

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.

• As Product Owner, @lfrohlich will decide if ACs are met — reviewed and approved by @lfrohlich.

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? — Yes, see *.test.js files
• Are code coverage minimums met?
  • Frontend coverage

Deliverable 3: Properly Styled Code

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

Acceptable Quality Level: 0 linting errors and 0 warnings

• 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

• Automated and manual testing with @iamjolly and @ttran-hub using Accessibility Insights caught one a11y issue — fixed and addressed by @jorgegonzalez !

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? — Yes, see inline code comments

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

• OWASP Scan passes on CircleCI
• Manual code review and manual testing pass

[alexsoble]

Approved! See QASP review, above. Thanks for your work on this @jorgegonzalez!