-
Notifications
You must be signed in to change notification settings - Fork 19
Caseflow Dispatch
❗ Not to be confused with: ❗
- the AMA Dispatch code
- React Action Dispatching
- the BVA Dispatch Organization
Caseflow Dispatch is the code that handles taking completed cases from VACOLS and creating End Products in VBMS. It sits at the same application level as Caseflow Hearings or Caseflow Queue.
A nightly job checks for cases ready for Full or Partial Grants, and creates the EstablishClaim object for it in Caseflow. Establish Claims collect, awaiting processing.
Processing is initiated in the Caseflow Dispatch application when a user with either the Establish Claim
or Manage Claim Establishment
role selects the "Establish Claim" button at /dispatch/establish-claim
.
[todo, screenshot stage1]
Next at Review Decision the user is prompted to review a document (open question: which doc?) and select any applicable Special Issues for the case. Some special issues create special routing steps later in the process, while others are informational. [todo, screenshot stage2]
In the default routing path, the user then reviews their selection before creating the end product. [todo, screenshot stage3]
Some Special Issues may trigger alternative routes [todo, screenshots alt_routes]
Supervisors (like css_id: "AMCASURL") can view pending claims at https://appeals.cf.ds.va.gov/dispatch/work-assignments This page has links to other reports.
TODO which SI trigger a new route, which new route, etc
TODO draw the obj model
A nightly job [TODO fetch list] checks VACOLS for cases in a particular set of statuses:
Full Grants: VBMS cases in HIS status (BVA action completed) with allowed issue(s) and no remanded issue(s) since [TODO the param date]
Partial Grants: VBMS cases in Remand statue, sitting in location 97.
And creates a new EstablishClaim, if one doesn't already exist.
EstablishClaims are a type of Dispatch::Task, which controls the flow via a state engine (AASM).
:unprepared -> :unassigned -> :assigned -> :started -> :reviewed -> :completed
with :reviewed
being optional depending on the dispatch process.
EstablishClaims are :assigned
when a user clicked "Establish Claim" in Caseflow Dispatch
They are :completed
after the EndProduct has been established in VBMS.
For the full state machine, reference the code.
The final output of Caseflow Dispatch is the End Product being created in VBMS
TODO: caseflow models around End Product
Goal: Migrate info discovered here into the main content above
2020-07-13 Caseflow Dispatch Users Investigation
https://hackmd.io/SJuHH4e5TmajVBPC562Y2A?view --- tags: investigation --- :::success :ballot_box_with_check: Done ::: # 2020-07-13 Caseflow Dispatch Users InvestigationAdding New Contentions.... done?
gaaaaah, who the eff uses Caseflow Dispatch so we can actually ask them what they need.
what does this look like again in the code
oh, good job past me! https://github.com/department-of-veterans-affairs/caseflow/wiki/Caseflow-Dispatch
EstablishClaim object
EstablishClaim.first
=> #<EstablishClaim:0x0000562cbb498b88
id: 1,
aasm_state: "unassigned",
appeal_id: 16,
assigned_at: nil,
comment: nil,
completed_at: nil,
completion_status: nil,
created_at: Fri, 10 Jul 2020 15:24:00 UTC +00:00,
lock_version: 1,
outgoing_reference_id: nil,
prepared_at: Thu, 09 Jul 2020 00:00:00 UTC +00:00,
started_at: nil,
type: "EstablishClaim",
updated_at: Thu, 09 Jul 2020 00:00:00 UTC +00:00,
user_id: nil>
started at and user_id look good to me
> EstablishClaim.where("user_id IS NOT NULL")
=> []
Test data doesn't have any with a user; building hte query with updated_at and appeal id...
EstablishClaim.where("updated_at >= ?", 1.month.ago)
EstablishClaim.where("updated_at >= ?", 1.month.ago).where("appeal_id IS NOT NULL").pluck("appeal_id")
EstablishClaim.where("updated_at >= ?", 1.month.ago).where("appeal_id IS NOT NULL").pluck("appeal_id").uniq
Ok! prod query:
EstablishClaim.where("started_at >= ?", 1.month.ago).where("user_id IS NOT NULL").pluck(:user_id).uniq
Prod:
irb(main):001:0> user_ids = EstablishClaim.where("started_at >= ?", 1.month.ago).where("user_id IS NOT NULL").pluck(:user_id).uniq
[2020-07-13 11:27:22 -0400] (32.5ms) SELECT "dispatch_tasks"."user_id" FROM "dispatch_tasks" WHERE "dispatch_tasks"."type" IN ('EstablishClaim') AND (started_at >= '2020-06-13 15:27:22.411049') AND (user_id IS NOT NULL)
=> [481, 16334, 484, 16231, 462, 6000, 1695, 1637, 1735, 1676, 16400, 13546, 14731]
irb(main):003:0> pp user_ids.sort.map { |user_id| user = User.find(user_id); [user.id, user.full_name, user.email] }
[[462, "LARRY BARNES", "[email protected]"],
[481, "PAUL PETERSON", "[email protected]"],
[484, "ARTHUR JENKINS", "[email protected]"],
[1637, "DANOMI BROWN", "[email protected]"],
[1676, "STEPHANY BRADFORD", "[email protected]"],
[1695, "CAROLYN MCCLARY", "[email protected]"],
[1735, "CHRISTOPHER JONES", "[email protected]"],
[6000, "CHANTEL GONZALEZ-SCOTT", "[email protected]"],
[13546, "WILLIAM ROLLINS", "[email protected]"],
[14731, "EVAN TRAN", "[email protected]"],
[16231, "KEYANA RUSSELL", nil],
[16334, "AVITA CARR", nil],
[16400, "KIMBERLY STEWART", "[email protected]"]]
irb(main):015:0> pp EstablishClaim.where("started_at >= ?", 1.month.ago).where("user_id IS NOT NULL").order(:user_id).group(:user_id).count
[2020-07-13 11:35:37 -0400] (32.4ms) SELECT COUNT(*) AS count_all, "dispatch_tasks"."user_id" AS dispatch_tasks_user_id FROM "dispatch_tasks" WHERE "dispatch_tasks"."type" IN ('EstablishClaim') AND (started_at >= '2020-06-13 15:35:37.746578') AND (user_id IS NOT NULL) GROUP BY "dispatch_tasks"."user_id" ORDER BY "dispatch_tasks"."user_id" ASC
{462=>898,
481=>1379,
484=>201,
1637=>311,
1676=>57,
1695=>199,
1735=>51,
6000=>398,
13546=>15,
14731=>2,
16231=>291,
16334=>162,
16400=>57}
user id | cases dispatched this month | Name | |
---|---|---|---|
462 | 898 | LARRY BARNES | [email protected] |
481 | 1379 | PAUL PETERSON | [email protected] |
484 | 201 | ARTHUR JENKINS | [email protected] |
1637 | 311 | DANOMI BROWN | [email protected] |
1676 | 57 | STEPHANY BRADFORD | [email protected] |
1695 | 199 | CAROLYN MCCLARY | [email protected] |
1735 | 51 | CHRISTOPHER JONES | [email protected] |
6000 | 398 | CHANTEL GONZALEZ-SCOTT | [email protected] |
13546 | 15 | WILLIAM ROLLINS | [email protected] |
14731 | 2 | EVAN TRAN | [email protected] |
16231 | 291 | KEYANA RUSSELL | nil |
16334 | 162 | AVITA CARR | nil |
16400 | 57 | KIMBERLY STEWART | [email protected] |
- Home
- Acronyms and Glossary
- Caseflow products
- Caseflow Intake
- Caseflow Queue
- Appeals Consumer
- Caseflow Reader
- Caseflow eFolder
- Caseflow Hearings
- Caseflow Certification
- Caseflow APIs
- Appeal Status API
- Caseflow Dispatch
-
CSUM Roles
- System Admin
- VHA Team Management
- Active Record Queries Resource
- External Integrations
- Caseflow Demo
- Caseflow ProdTest
- Background
- Stuck Jobs
- VA Notify
- Caseflow-Team
- Frontend Best Practices
- Accessibility
- How-To
- Debugging Tips
- Adding a Feature Flag with FeatureToggle
- Editing AMA issues
- Editing a decision review
- Fixing task trees
- Investigating and diagnosing issues
- Data and Metric Request Workflow
- Exporting and Importing Appeals
- Explain page for Appeals
- Record associations and Foreign Keys
- Upgrading Ruby
- Stuck Appeals
- Testing Action Mailer Messages Locally
- Re-running Seed Files
- Rake Generator for Legacy Appeals
- Manually running Scheduled Jobs
- System Admin UI
- Caseflow Makefile
- Upgrading Postgresql from v11.7 to v14.8 Locally
- VACOLS VM Trigger Fix M1
- Using SlackService to Send a Job Alert
- Technical Talks