5390 feedback reports admin UI

[mattcoleanderson]

Summary of Changes

Provide a brief summary of changes
Pull request closes #5390

How to Test

List the steps to test the PR
These steps are generic, please adjust as necessary.

cd tdrs-frontend && docker-compose up --build
cd tdrs-backend && docker-compose up --build

1. Open http://localhost:3000/ and sign in.
2. Proceed with functional tests as described herein.
3. Test steps should be captured in the demo GIF(s) and/or screenshots below.

Demo GIF(s) and screenshots for testing procedure

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• [insert ACs here]
• lfrohlich and/or adpennington confirmed that ACs are met.

Deliverable 2: Tested Code

• 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: [insert coverage %] (see CodeCov Report comment in PR)
  • Backend coverage: [insert coverage %] (see CodeCov Report comment in PR)

Deliverable 3: Properly Styled Code

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Are code maintainability principles being followed?

Deliverable 4: Accessible

• Does this PR complete the epic?
• Are links included to any other gov-approved PRs associated with epic?
• Does PR include documentation for Raft's a11y review?
• Did automated and manual testing with iamjolly and ttran-hub using Accessibility Insights reveal any errors introduced in this PR?

Deliverable 5: Deployed

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

Deliverable 6: Documented

• Does this PR provide background for why coding decisions were made?
• If this PR introduces backend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces frontend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces dependencies, are their licenses documented?
• Can reviewer explain and take ownership of these elements presented in this code review?

Deliverable 7: Secure

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any new security issues?
• If new issues detected, is investigation and/or remediation plan documented?

Deliverable 8: User Research

Research product(s) clearly articulate(s):

• the purpose of the research
• methods used to conduct the research
• who participated in the research
• what was tested and how
• impact of research on TDP
• (if applicable) final design mockups produced for TDP development

[codecov]

Codecov Report

❌ Patch coverage is 93.45794% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.01%. Comparing base (8bd35c1) to head (9255c14).
⚠️ Report is 1 commits behind head on develop.

Files with missing lines	Patch %	Lines
...src/components/FeedbackReports/FeedbackReports.jsx	91.42%	3 Missing and 3 partials ⚠️
tdrs-frontend/src/components/SiteMap/SiteMap.jsx	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop    #5486    +/-   ##
=========================================
  Coverage    92.00%   92.01%            
=========================================
  Files          471      474     +3     
  Lines        20162    20269   +107     
  Branches       439      460    +21     
=========================================
+ Hits         18550    18650   +100     
- Misses        1531     1534     +3     
- Partials        81       85     +4     

Flag	Coverage Δ
dev-backend	92.20% <ø> (ø)
dev-frontend	90.48% <93.45%> (+0.14%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ponents/FeedbackReports/FeedbackReportsHistory.jsx	100.00% <100.00%> (ø)
...mponents/FeedbackReports/FeedbackReportsUpload.jsx	100.00% <100.00%> (ø)
tdrs-frontend/src/components/Header/Header.jsx	100.00% <100.00%> (ø)
tdrs-frontend/src/components/Routes/Routes.js	84.61% <ø> (ø)
tdrs-frontend/src/selectors/auth.js	98.00% <100.00%> (+0.08%)	⬆️
tdrs-frontend/src/components/SiteMap/SiteMap.jsx	94.11% <50.00%> (-5.89%)	⬇️
...src/components/FeedbackReports/FeedbackReports.jsx	91.42% <91.42%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9636cfa...9255c14. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jtimpe]

Good work!

[raftmsohani]

wondering what happens if the number of uploads are more than for example 50? I understand this might never happen but it might make sense to add pagination maybe?

[mattcoleanderson]

There is pagination from the backend by default. Currently only 32 records are returned from the backend. So if more than 32 items are present, then the table will display only those items in pages of 5 because of the PaginatedComponent.

It looks like the SubmissionHistory tables turn backend pagination off and filter on the frontend only. Wouldn't be a good idea here though, since this table doesn't have any subfilters it just shows the entire ReportSource table.

@elipe17 @jtimpe What do y'all think? Do we need to support traversing every stored uploaded report in this table? If so, a better solution than the PaginatedComponent may be needed. Maybe an load the next 32 items when you click the last page.

Or we could use an elipsis to signify more records that could be loaded. Load them when that is clicked.

[mattcoleanderson]

UPDATE: In office hours we discussed writing a follow on ticket to add a year selector which should be good enough. I will also write another ticket for implementing actual pagination in the future.

[victoriaatraft]

hi @mattcoleanderson if select Feedback Reports in the menu, I'm taken to the home page

[victoriaatraft]

@mattcoleanderson

Couple questions:

• How does the system determine which states are notified?
• Can we clear the upload section, after the user selects Upload & notify States?
• I tried modifying the zip file to resolve the error, but still getting returned that state. How do I get a successful status without an error? Given that, I'm still getting a "successful" banner

✅ a11y check passed

[mattcoleanderson]

@victoriaatraft

• How does the system determine which states are notified?

When a report is submitted, the STT is determined by the folder structure of the zip file. For example if the following folder is submitted:

2025/
  └── 4/
      ├── 01/
      │   └── alabama_report.pdf
      └── 12/
          └── florida_report.pdf

The STT will be parsed from the 3rd directory:

• 2025 - Fiscal Year
• 4 - Region (not used but is expected to be present)
• 01 - STT Code
• alabama_report.pdf - contents to be zipped and associated to an STT. content here does not matter for parsing

• Can we clear the upload section, after the user selects Upload & notify States?

This is something we've attempted to do with TANF and FRA uploads before and due to various issues, have settled with not clearing the selection after upload for those submission pages. I think we should do the same for this one.

• I tried modifying the zip file to resolve the error, but still getting returned that state. How do I get a successful status without an error? Given that, I'm still getting a "successful" banner

So the "successful" banner is to indicate that your report was successfully uploaded, not that it was successfully parsed. This directory has various zip files that will fail or pass for various reasons that you can submit, as well as a READ.me that explains why they fail and what their folder structure is: https://github.com/raft-tech/TANF-app/tree/5417-feeback-reports-stt-ui/tdrs-backend/tdpservice/reports/test/data

It should help you understand the proper tree structure for the zip file

[victoriaatraft]

Couple notes transferring here from our DM -- but all looks good given your answers and my testing!

Let's title case the status so that they're consistent with other pages ie: Failed, Pending etc
And since Succeeded means the zip file was parsed and the notification sent, I'd like to suggest changing that status to
Parsed & Notified, Failed and Pending

cc @reitermb @mattcoleanderson

[reitermb]

Second the above.

Maybe more of a broader question than for just this PR, but @mattcoleanderson do you happen to know when we made the swap from always-enabled submit buttons with error text (if the user attempts to submit without a file) to the current implementation with disabled state buttons? I'm blanking on whether we had any cross-functional discussion on that.

I think at the very least we might need to tweak the behavior of uswds disabled buttons if we keep that to make them play a little nicer with screenreaders.