Calvin/APPEALS-44957-rake-affinity

[calvincostaBAH]

Resolves APPEALS-44957

Description

As a developer I need to add a Rake task to “seed” the initial affinity_start_date in all environments, including updating existing local/demo seed data, so that affinity day counters begin the hold period accurately based on the distribution of matching appeals, ensuring timely distribution to the affinitized judge.

-Added rake task to seed affinity_start_date for all ready to distribute appeals with a correlating type, priority, and receipt date to the most recently distributed appeal.
-Added rspec test for rake task

Acceptance Criteria

• When the Rake task is executed, it retrieves the receipt_date for the most recent distributed appeals for each of the following docket types and priority statuses:

  1.     Priority Direct Review Docket
  2.     Priority Evidence Submission Docket
  3.     Priority Hearing Request Docket
  4.     Priority Legacy Docket
  5.     Non-priority Direct Review Docket
  6.     Non-priority Evidence Submission Docket
  7.     Non-priority Hearing Request Docket
  8.     Non-priority Legacy Docket
  

• Using the receipt_date obtained, the Rake task identifies all ready-to-distribute appeals of each corresponding type and priority status (priority or non-priority) with an affinity_start_date equal to or older than the retrieved receipt_date, or with no appeal_affinity record.

• The Rake task creates or updates the affinity_start_date records for the identified appeals, ensuring they align with the receipt_date of the most recent distributed appeals of their respective type and priority status.

• The Rake task completes successfully without errors and can be executed in all environments

Testing Plan

1. Go to Jira Issue/Test Plan Link or list them below

• 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?