3180 - error type field

[jtimpe]

Summary of Changes

Pull request closes #3180

• Adds the "error type" column back to the generated error report, this time with the "friendly" label instead of the numeric value

How to Test

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

1. Open http://localhost:3000/ and sign in.
2. Download an error report. Examine the "error type" column for each error in the report

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• (friendly version) Error Type column appears in error reports
• Error type column appears as the right-most column
• 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

All modified and coverable lines are covered by tests ✅

Project coverage is 92.66%. Comparing base (a981311) to head (022d9c4).
Report is 6 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3202   +/-   ##
========================================
  Coverage    92.66%   92.66%           
========================================
  Files           47       47           
  Lines         1009     1009           
  Branches       169      169           
========================================
  Hits           935      935           
  Misses          42       42           
  Partials        32       32           

Flag	Coverage Δ
dev-frontend	92.66% <ø> (ø)

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

---

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 c5f87eb...022d9c4. Read the comment docs.

[raftmsohani]

LGTM!

[elipe17]

LGTM

[ADPennington]

this is in great shape @jtimpe 🥇 -- approval coming up tomorrow. I'd just like to firm up release note next steps with UX team at our sync tmor morning before this closes.

[ADPennington]

appreciate the quick change @jtimpe 👍🏾

• Evidence of the updated error report is here
• Really nice to see that this change applies to new and previously-generated error reports, so resubmission or reparsing command isn't needed to access the error type.
• I'm hopeful that the release notes, KC guidance, and UX research can help inform if the error type "friendly names" are easy-to-understand. As is, I think we should expect clarifying questions, which is 🆗 for now. cc: @klinkoberstar @ttran-hub @victoriaatraft @reitermb