Added Aoj Aod affinity days in distribute appeals

[samasudhirreddy]

Resolves APPEALS-43901

Description

• Added aoj_aod_affinity days lever to the aoj_case_docket methods
• Added aoj_aod_affinity_filter to the aoj_case_docket methods
• Added seed data for aoj_aod cases in the db/seeds/aoj_remand_return_legacy_appeals.rb file
• Added rspec test cases for the new aoj_aod_affinity days lever and aoj_aod_affinity days filter to the spec/models/vacols/aoj_case_docket_spec.rb
• Updated related rspecs to include the aoj_aod_affinity days lever
• Removed code that was causing issues with the JOIN_PREVIOUS_APPEALS query in both case_docket.rb and aoj_case_docket.rb to be consistent

Acceptance Criteria

• • [ ] As noted in Dev epic APPEALS-27523 ac/6 The following distribution rules are applied to AOJ remands unless otherwise noted.
• If the affinitized judge is available to receive appeals, Caseflow will not distribute the appeal to another judge before the number of days specified in the applicable affinity days lever has elapsed. (This is the setting Attempt distribution to current judge for max of )
• If the most recent remanding judge is unavailable or does not receive the appeal through a distribution or case movement within the number of days specified in the applicable affinity days, the appeal will be distributed to any judge who is eligible to receive appeals.
• If the lever is set to Omit variable from distribution, the appeal is distributed to any judge who is eligible to receive appeals.
• Always distribute to the current judge will return the appeal to the affinitized judge regardless of the amount of time it takes to do so.
• If the remanding judges is no longer with the board, the appeal is distributed to any judge who is eligible to receive appeals.
• For AOJ Remand Returned appeals with a Hearing Held
• Determine if an affinity applies to the appeal:
• If the most-recent remanding judge also conducted the most recent hearing, always return the appeal to the hearing judge unless that judge is no longer with the board. (Does not follow affinity rule because it is tied to the judge)
• If that judge is no longer with the board, the appeal is distributed to any judge who can receive appeals.
• If the deciding judge did not conduct the hearing, apply the affinity rule applicable for the appeal conditions.
• AOJ Remand Returned appeals (that are not any of the combinations specified below) with a hearing held follow the distribution rules in A/C 1 and apply AOJ affinity days variable.
• AOJ + AOD Remand Returned appeals with a hearing held (whether it was or was not at any time a CAVC appeal) follow the distribution rules in A/C 1 and apply AOJ AOD affinity days variable.
• AOJ Remand Returned appeals with a hearing held that was also at one time a CAVC Remand follow the distribution rules in A/C 6 and apply AOJ CAVC affinity days variable.
• AOJ Remand Returned appeals without a hearing held are distributed according the rules in A/C 1 and use the affinity days variables specified below:
• AOJ Remand Returned appeals without a hearing held that are not also AOD and/or CAVC use the AOJ affinity days variable.
• All AOJ Remand Returned appeals without a hearing that are also AOD (with or without being CAVC at one time) use the AOJ AOD affinity days variable.
• All AOJ Remand Returned appeals without a hearing held that were at one time CAVC use the AOJ CAVC affinity day variable.
• AOJ Remand Returned stats are now included in priority and non-priority values in the distribution_stats database table to be used for reporting
• The priority stat will be the number of currently ready-to-distribute priority legacy AOJ Remands Returned at the time of a distribution.
• The non-priority stat will be the number of currently ready-to-distribute non-priority legacy AOJ Remands Returned at the time of a distribution.
• Uses aoj_aod_affinity_days lever
• Seed data is created for testing in demo.

Testing Plan

To run the seed file in the rails console, run make clean && bundle exec rake db:seed:aoj_remand_return_legacy_appeals

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