Tribal Section 4 Parsing & Validation

[elipe17]

Summary of Changes

• Added support for section 4 parsing and validation
  Pull request closes Tribal TANF Stratum Data (04) File Parsing - As a data analyst, I want my data files to be parsed so that my submission can be validated/accepted by TDP #1117

How to Test

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

• Open http://localhost:3000/ and sign in.
• Submit tribal_section_4_fake.txt.
• Verify the file generates Tribal T7 records.

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• Allow Tribes to submit stratum Data based on the TANF data parsing spec
• Testing Checklist has been run and all tests pass
• README is updated, if necessary

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

[ADPennington]

@elipe17 i discovered an issue with this validator.

• If the quarter is a space, then no error is raised in the logs or the feedback report
• if the quarter = 0 or > 4, then this message is returned in the logs Invalid quarter value. and the processing status stays in the "pending" state which does not generate a feedback report.

I believe this is an edge case, but does need to be addressed in a new ticket.

[ADPennington]

#2807

[ADPennington]

checked this. lgtm 👍🏾

[ADPennington]

@elipe17 this is ready to merge. i created a new ticket to clean up the validation for cal qtr since this field is present in several schemas. Great work! 🚀