You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a hearing coordinator, I want hearings that I convert from Travel Board to virtual to show up in the RO queues (more or less) immediately so I can more quickly shift to building dockets.
Background
Currently we rely on the background jobs to geo-match and cache these appeals, but depending on the number of appeals with open tasks it can take several hours to successfully show up in the RO queue. Coordinators are looking to convert a number of Travel Board hearings in a row, head over the RO queue, filter their queue to show only virtual/former Travel Board, and start building docket days.
Acceptance criteria
When a user completes the "Convert hearing to virtual" action on a Travel Board hearing, it immediately shows up in the geo-matched RO queue
Technical notes
We can geo-match and cache on the fly as part of the conversion process. This will affect performance because we're making a call to VA.gov and maybe a request to VACOLS.
We will have to do these asynchronously. We may not have to do the geomatching because it should be geomatched already.
We don't have a way to cache individual appeals with the current job. It would have to be modified to accept arguments to run against a single appeal.
Are there race conditions that could be created by starting the job for an individual appeal when the existing job is already running?
The text was updated successfully, but these errors were encountered:
Resolves#15426
### Description
- Moved `FetchHearingLocationsForVeteransJob` logic to `GeomatchService`
- Moved `UpdateCachedAppealsAttributesJob` logic to `CachedAppealService`
- Refactored some existing logic to get rid of some CodeClimate warnings. The remaining ones I think we can ignore
- Add `Hearings::GeomatchAndCacheAppealJob`, and start it when completing `ChangeHearingRequestTypeTask`
- Update and add tests
- Resolves merge conflicts from #15482 and #15478
### Acceptance Criteria
- [x] When a user completes the "Convert hearing to virtual" action on a Travel Board hearing, it immediately shows up in the geo-matched RO queue
### Testing Plan
1. Login as BVASYELLOW
2. Go to http://localhost:3000/queue/appeals/1986897
3. Work the change appeal type task
4. Go to the schedule veteran page for St. Petersburg, and ensure the case shows up
User story
As a hearing coordinator, I want hearings that I convert from Travel Board to virtual to show up in the RO queues (more or less) immediately so I can more quickly shift to building dockets.
Background
Currently we rely on the background jobs to geo-match and cache these appeals, but depending on the number of appeals with open tasks it can take several hours to successfully show up in the RO queue. Coordinators are looking to convert a number of Travel Board hearings in a row, head over the RO queue, filter their queue to show only virtual/former Travel Board, and start building docket days.
Acceptance criteria
Technical notes
We can geo-match and cache on the fly as part of the conversion process. This will affect performance because we're making a call to VA.gov and maybe a request to VACOLS.
We will have to do these asynchronously. We may not have to do the geomatching because it should be geomatched already.
We don't have a way to cache individual appeals with the current job. It would have to be modified to accept arguments to run against a single appeal.
Are there race conditions that could be created by starting the job for an individual appeal when the existing job is already running?
The text was updated successfully, but these errors were encountered: