TYLERB/APPEALS-30892: Report Generation through ‘Generate task report’ button

[TylerBroyles]

Resolves APPEALS-30892
Epic link: https://jira.devops.va.gov/browse/APPEALS-26499

Description

The primary purpose of this PR is to link the Report Page form submission, the change history event generation, and the csv creation together. This PR also creates all of the mappings between the form values and the backend values in the ReportPage.jsx ui component and the DecisionReviewsController in order to prepare the values for use in event generation. In addition to the primary focus, there were additional changes made to the change history query to accommodate AttorneyClaimants and Unrecognized claimants. The query was also changed to work with the completed_by_id field on a task in addition to the already working task version whodunnit value for determining which user completed a task/disposition.

Acceptance Criteria

• CSV
  • The CSV fields for each event type match the example CSV or what UI/UX has decided it should be
  • Name of the .csv is ‘taskreport-date_time.csv’ e.g.taskreport-20231122_1323.csv.
  • The filter params are displayed as the first row of the CSV and it matches designs
  • The second row of the CSV is the column headers and it matches designs
  • The CSV generated has the correct event data for the filters that were given
• Report Generation
  • Status report
    • All statuses can be generated with any number of conditions
    • Specific statuses can be generated with any number of conditions
    • Last action taken can be generated with any number of conditions
    • Summary can be generated with any number of conditions
  • Event report
    • All events report can be generated with or without timing
    • Specific events report can be generated with or without timing
  • Conditions
    • Issue dispositions condition is passed down and correctly used in the event generation
    • Issue Types condition is passed down and correctly used in the event generation
    • Facilities condition is passed down and correctly used in the event generation
    • Personnel condition is passed down and correctly used in the event generation
    • Days waiting condition is passed down and correctly used in the event generation
  • General form behavior
    • The ui accurately reflects that a CSV is being generated and indicates that a CSV has been generated
    • The submission button is disabled while the CSV is being generated
    • The Form fields do not get reset after clicking the submit button
    • The Clear filters button should reset the form to a default state and none of the original form data should be used if the form is submitted again

Testing Plan

1. Login as a user that is an admin of the vha business line.
2. Navigate to the report page at the url /decision_reviews/vha/report
3. On the Report page verify that you can generate a report by clicking and that it creates a CSV with the file name of taskreport-date_time.csv.
4. Verify that the filter row in the CSV includes the report type of event and timing.
5. Verify that the column header rows in the CSV is correct and matches the designed spreadsheet.
6. Verify that the event rows are correct for your data
7. Try out an event submission with specific events filtered and a timing
8. Try out a status submission with the last action taken submitted and verify that each task in your data only has one event per task in the CSV and it's the last action taken on that task.
9. Try a status submission of type summary. It should be the exact same results as a default event report submission.
10. Try an Issue Type condition with one or many values and verify that the data is only issues that include that issue type.
11. Try an Issue Disposition condition with one or many values and verify that the data is only issues that include that disposition value
12. Try a days waiting condition and verify the data
13. Try a facilities condition and verify that the events showing were performed by a user from that station.
14. Try a personnel condition (it can't be done at the same time as facilities) and verify that the events in the CSV were performed by that user
15. Try a decision reviews condition and verify that the events showing are of the correct claim type that you selected.
16. Try a lot of different permutations of various conditions and report types until satisfied.

• For feature branches merging into master: Was this deployed to UAT?

Frontend

User Facing Changes

• Screenshots of UI changes added to PR & Original Issue

BEFORE	AFTER

Storybook Story

For Frontend (Presentation) Components

• Add a Storybook file alongside the component file (e.g. create MyComponent.stories.js alongside MyComponent.jsx)
• Give it a title that reflects the component's location within the overall Caseflow hierarchy
• Write a separate story (within the same file) for each discrete variation of the component

Backend

Database Changes

Only for Schema Changes

• Add typical timestamps (created_at, updated_at) for new tables
• Update column comments; include a "PII" prefix to indicate definite or potential PII data content
• Have your migration classes inherit from Caseflow::Migration, especially when adding indexes (use add_safe_index) (see Writing DB migrations)
• Verify that migrate:rollback works as desired (change supported functions)
• Perform query profiling (eyeball Rails log, check bullet and fasterer output)
• For queries using raw sql was an explain plan run by System Team
• Add appropriate indexes (especially for foreign keys, polymorphic columns, unique constraints, and Rails scopes)
• Run make check-fks; add any missing foreign keys or add to config/initializers/immigrant.rb (see Record associations and Foreign Keys)
• Add belongs_to for associations to enable the schema diagrams to be automatically updated
• Document any non-obvious semantics or logic useful for interpreting database data at Caseflow Data Model and Dictionary

Integrations: Adding endpoints for external APIs

• Check that Caseflow's external API code for the endpoint matches the code in the relevant integration repo
  • Request: Service name, method name, input field names
  • Response: Check expected data structure
  • Check that calls are wrapped in MetricService record block
• Check that all configuration is coming from ENV variables
  • Listed all new ENV variables in description
  • Worked with or notified System Team that new ENV variables need to be set
• Update Fakes
• For feature branches: Was this tested in Caseflow UAT

Best practices

Code Documentation Updates

• Add or update code comments at the top of the class, module, and/or component.

Tests

Test Coverage

Did you include any test coverage for your code? Check below:

• RSpec
• Jest
• Other

Code Climate

Your code does not add any new code climate offenses? If so why?

• No new code climate issues added

Monitoring, Logging, Auditing, Error, and Exception Handling Checklist

Monitoring

• Are performance metrics (e.g., response time, throughput) being tracked?
• Are key application components monitored (e.g., database, cache, queues)?
• Is there a system in place for setting up alerts based on performance thresholds?

Logging

• Are logs being produced at appropriate log levels (debug, info, warn, error, fatal)?
• Are logs structured (e.g., using log tags) for easier querying and analysis?
• Are sensitive data (e.g., passwords, tokens) redacted or omitted from logs?
• Is log retention and rotation configured correctly?
• Are logs being forwarded to a centralized logging system if needed?

Auditing

• Are user actions being logged for audit purposes?
• Are changes to critical data being tracked ?
• Are logs being securely stored and protected from tampering or exposing protected data?

Error Handling

• Are errors being caught and handled gracefully?
• Are appropriate error messages being displayed to users?
• Are critical errors being reported to an error tracking system (e.g., Sentry, ELK)?
• Are unhandled exceptions being caught at the application level ?

Exception Handling

• Are custom exceptions defined and used where appropriate?
• Is exception handling consistent throughout the codebase?
• Are exceptions logged with relevant context and stack trace information?
• Are exceptions being grouped and categorized for easier analysis and resolution?

[codeclimate]

Code Climate has analyzed commit cc807cb and detected 0 issues on this pull request.

View more on Code Climate.