Caseflow: [Epic] Prevent duplicate TranslationTasks for an appeal

Created on 21 Jun 2019  路  10Comments  路  Source: department-of-veterans-affairs/caseflow

The Translation team noticed that there are multiple tasks in their queue for the same appeal for two reasons.

  1. The application automatically created a TranslationTask and Board employees later created another TranslationTask manually.
  2. ColocatedTasks with open child TranslationTasks were marked as complete and additional ColocatedTasks with child TranslationTasks were created.

We were able to make these determinations by running the following SQL query:

select appeal_id
, appeal_type
, count(*)
from tasks
where type = 'TranslationTask'
  and assigned_to_type = 'Organization'
group by 1, 2
having count(*) > 1;

Which revealed the following six appeals had multiple open TranslationTasks: 806, 1271, 1439, 2222, 2280, and 2649. Digging into the task trees for these appeals we saw two patterns.

First, ColocatedTasks are able to be completed even if they have open child tasks. Two of the six appeals with duplicate TranslationTasks had the duplicate tasks created when there were already open TranslationTasks. The questions I'd like to answer is if we are not making this obvious enough for Caseflow users (that there is an open TranslationTask), if users know there is an open TranslationTask and just don't know what to do so they create another one, or if we should just prevent the ColocatedTask from being closed in the first place? I'm in favor of the last option here, but am curious what others think.

In order to clean up the duplicated TranslationTasks from this situation, I propose we cancel the TranslationTasks that are children of closed ColocatedTasks, leaving open the TranslationTasks with open ColocatedTasks.

Second, TranslationTasks are created automatically when an appeal for a Veteran who lives in Philippines or Puerto Rico is taken in to Caseflow. These TranslationTasks do not block distribution, so we can distribute these appeals to judges and attorneys, at which time they might notice that documents in the file need to be translated and create additional TranslationTasks. The remaining four of six appeals with duplicate TranslationTasks had TranslationTasks created manually from a ColocatedTask. I don't quite know what we expect Caseflow users to do in this situation, and am curious to get @laurjpeterson, @sneha-pai, and @pkarman's opinion here.

In order to clean up the duplicated TranslationTasks from this situation, I propose we cancel the TranslationTasks that were created automatically on intake, leaving open the TranslationTasks with open ColocatedTasks.

Long-term fixes

  • [ ] Determine how we want to prevent the application/manual duplication situation.
  • [ ] Write ticket to do the work to prevent the application/manual duplication situation.
  • [ ] Resolve currently duplicated appeals due to the application/manual TranslationTask duplication scenario.
  • [ ] Determine how we want to prevent the manual duplication scenario.
  • [ ] Write ticket to do the work to prevent the manual duplication scenario.

    • As a part of this ticket consider getting rid of the actions_available? method entirely? Determine if there are any places we use that method that cannot be replaced with conditions in available_actions?

  • [ ] Resolve currently duplicated appeals with manually duplicated TranslationTasks.
co-located generic-queue caseflow-queue Echo 馃惉 Bug

Most helpful comment

The questions I'd like to answer is if we are not making this obvious enough for Caseflow users (that there is an open TranslationTask), if users know there is an open TranslationTask and just don't know what to do so they create another one, or if we should just prevent the ColocatedTask from being closed in the first place? I'm in favor of the last option here, but am curious what others think.

  • I'm also curious about if it's not clear to users what tasks are open. We'd have to sit with VLJ Support Staff to learn this.
  • I don't understand ColocatedTasks being closed, but it could be Friday brain. I wonder if users should be prevented to create a second TranslationTask if there is already an open one?

The remaining four of six appeals with duplicate TranslationTasks had TranslationTasks created manually from a ColocatedTask. I don't quite know what we expect Caseflow users to do in this situation, and am curious to get @laurjpeterson, @sneha-pai, and @pkarman's opinion here.

Some thoughts:

  • I ask stakeholders if TranslationTasks should block distribution so attorneys don't get cases with docs needing translation, causing them to create a second TranslationTask. If it's true, then we should just make TranslationTasks blocking distribution and prevent this situation from occurring in the future.
  • We find some way to link the Colocated TranslationTask with the automatically created TranslationTask, so when the automatically created TranslationTask is completed, the case goes back to the attorney who assigned the Colocated TranslationTask

All 10 comments

The questions I'd like to answer is if we are not making this obvious enough for Caseflow users (that there is an open TranslationTask), if users know there is an open TranslationTask and just don't know what to do so they create another one, or if we should just prevent the ColocatedTask from being closed in the first place? I'm in favor of the last option here, but am curious what others think.

  • I'm also curious about if it's not clear to users what tasks are open. We'd have to sit with VLJ Support Staff to learn this.
  • I don't understand ColocatedTasks being closed, but it could be Friday brain. I wonder if users should be prevented to create a second TranslationTask if there is already an open one?

The remaining four of six appeals with duplicate TranslationTasks had TranslationTasks created manually from a ColocatedTask. I don't quite know what we expect Caseflow users to do in this situation, and am curious to get @laurjpeterson, @sneha-pai, and @pkarman's opinion here.

Some thoughts:

  • I ask stakeholders if TranslationTasks should block distribution so attorneys don't get cases with docs needing translation, causing them to create a second TranslationTask. If it's true, then we should just make TranslationTasks blocking distribution and prevent this situation from occurring in the future.
  • We find some way to link the Colocated TranslationTask with the automatically created TranslationTask, so when the automatically created TranslationTask is completed, the case goes back to the attorney who assigned the Colocated TranslationTask

@laurjpeterson Did we even confirm whether or not we wanted to make translation tasks blocking? https://dsva.slack.com/archives/C6E41RE92/p1561552583119500

Yes, it Rachel confirmed it should be blocking:

https://dsva.slack.com/archives/C6E41RE92/p1561556004126000?thread_ts=1561552583.119500&cid=C6E41RE92

yes, we think it should be blocked. a case with untranslated documents can be granted or remanded for other reasons, but in those circumstances the attorney should simply draft the decision - they should not even assign it to translation. so if a case was assigned to translation by the attorney, it should be blocked until the translation is complete.

Actions moving forward on this ticket:

  • [x] Update Translation Tasks to block case distribution to the judge until they are completed

    • #11654

  • [x] Make Translation Colocated Tasks put their parent task on hold

    • This already appears to be the case now!

  • [ ] Update existing Appeals in this state in production to match (place their parents on hold)

Production Cleanup work proposal documented here.

@laurjpeterson For discussion Monday! we have about ~20 appeals where I'd like your input on how to move forward, as they involve speaking with some combination of Translation & Attorney users.

Production Updated for these scenarios

Old good-structure (Translation Org sibling to Distribution), Distribution Task on_hold. Translation org task assigned or on_hold

63 Tasks updated.

root_tasks = DistributionTask.where(status: Constants.TASK_STATUSES.on_hold).pluck(:parent_id);
sure_root_tasks = RootTask.where(id: root_tasks).pluck(:id);
tasks_to_update = []
tasks_with_errors = []
translation_tasks = TranslationTask.where(status: [Constants.TASK_STATUSES.on_hold, Constants.TASK_STATUSES.assigned], assigned_to_type: Organization.name, parent_id: sure_root_tasks) 
translation_tasks.each do |translation_task|
   dist_task = DistributionTask.where(status: Constants.TASK_STATUSES.on_hold, parent_id: translation_task.parent_id)
   if dist_task.count != 1
     tasks_with_errors.push("Bad number of distribution tasks for translation_task #{translation_task.id}")
   else
     tasks_to_update.push(translation_task.id)
     translation_task.update!(parent_id: dist_task.first.id)                                                                  
   end
end
tasks_to_update.count
tasks_with_errors.count

Old good-structure (Translation Org sibling to Distribution), Distributuon Task assigned. Translation org task assigned or on_hold

30 tasks updated. (30 translation, 30 distribution)

root_tasks = DistributionTask.where(status: Constants.TASK_STATUSES.assigned).pluck(:parent_id);
sure_root_tasks = RootTask.where(id: root_tasks).pluck(:id);
tasks_to_update = []
tasks_with_errors = []
translation_tasks = TranslationTask.where(status: [Constants.TASK_STATUSES.on_hold, Constants.TASK_STATUSES.assigned], assigned_to_type: Organization.name, parent_id: sure_root_tasks) 
ActiveRecord::Base.logger.level = 0
translation_tasks.each do |translation_task|
   dist_task = DistributionTask.where(status: Constants.TASK_STATUSES.assigned, parent_id: translation_task.parent_id)
   if dist_task.count != 1
     tasks_with_errors.push("Bad number of distribution tasks for translation_task #{translation_task.id}")
   else
     tasks_to_update.push(translation_task.id)
     ActiveRecord::Base.transaction do
       translation_task.update!(parent_id: dist_task.first.id)    
       dist_task.first.update!(status: Constants.TASK_STATUSES.on_hold)
     end
   end
end
tasks_to_update.count
tasks_with_errors.count

All remaining cases (approximately two dozen) affected by the duplicated translation tasks will require a combination of manual intervention and user guidance.

Technical work is complete on this ticket.

@stwards11 Any updates on how this is going? Let me know if you need me to pull any info for the various situations.

@lomky I read through this thread and it looks like the technical work was completed, but there were some appeals that needed PM input. Is this still the case? This ticket is old and looking to determine if it can be closed or if there is an action I need to take here.

@araposo-tistatech That is correct! I would need to do a couple hours of work to rediscover the current state of the appeals needing input and what their options are/what info we need.

Was this page helpful?
0 / 5 - 0 ratings