Caseflow: Attorney task cleanup - Investigate why attorney's signed case is in On Hold

[laurjpeterson]

Attorney Andrew Zheng is seeing a signed decision in his On Hold queue.
CSS ID: VACOZHENGA3
Case details URL:
Support ticket: https://github.com/department-of-veterans-affairs/appeals-support/issues/3643

[msj0nes]

Open Tickets

CSS ID | Case Details URL
-- | --
VACOULLERJ  | https://appeals.cf.ds.va.gov/queue/appeals/2649463  
vacomillee | https://appeals.cf.ds.va.gov/queue/appeals/6fe29e4a-e3c6-4cfb-a2e6-d1a769257efc
bvaLCrohe | https://appeals.cf.ds.va.gov/queue/appeals/3800101
bvaNRippel| https://appeals.cf.ds.va.gov/queue/appeals/3864391

[lowellrex]

Likely related to bugs noted in #8095. Will address this issue next sprint (2 weeks starting 11 Feb) by improving the TaskTable component.

[lowellrex]

Made some progress on investigating this issue with @hschallhorn with AMA appeals (didn't dig into the Legacy Appeals). See notes below:

# Think this is happening because Board employees changed the location code away from
# CASEFLOW to somebody else, perhaps "charging" the case back to themselves so they
# could keep working.

# Let's see if we can VALIDATE THIS!
# If they are all legacy then this could certainly be the case.
# - Would only expect ColocatedTasks to be affected here.
# Let's take a look at one of the AMA Appeals to see if this is the same bug:

rails c> uuid = "6fe29e4a-e3c6-4cfb-a2e6-d1a769257efc"
rails c> appeal = Appeal.find_by(uuid: uuid)
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
# [[849, nil, "RootTask", "completed"],
   [1232, 849, "JudgeDecisionReviewTask", "completed"],
   [7078, 1232, "AttorneyTask", "completed"],
   [10624, 7078, "ColocatedTask", "completed"],
   [10625, 10624, "ColocatedTask", "completed"],
   [137090, 849, "BvaDispatchTask", "completed"],
   [137091, 137090, "BvaDispatchTask", "completed"]]
# This one has recovered. Let's find a different errored Appeal!

# https://github.com/department-of-veterans-affairs/appeals-support/issues/4508
rails c> uuid = "43f6eb59-c123-4c39-80da-fcfbd2aa5254"
rails c> appeal = Appeal.find_by(uuid: uuid)
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :instructions)
# [[951, nil, "RootTask", "on_hold", []],
 [15376, 951, "JudgeAssignTask", "on_hold", []],
 [34758, 15376, "AttorneyTask", "assigned", []],
 [67066,
  34758,
  "ColocatedTask",
  "completed",
  [ {{{ NOT POSTIN IN GITHUB }}} ]],
 [67067,
  67066,
  "ColocatedTask",
  "cancelled",
  [ {{{ NOT POSTIN IN GITHUB }}} ]],
 [152258,
  67066,
  "ColocatedTask",
  "cancelled",
  [ {{{ NOT POSTIN IN GITHUB }}} ]]]
# These instructions were written by an attorney for the VLJ support staff. I think
# this is a different issue entirely. What we want to happen is for there to be a new
# JudgeTask branch of the tree and the current JudgeTask branch to be closed out.
# We can do that. It's a different thing than the tasks being on hold for dispatched
# appeals.

# Are there any other tasks on hold for AMA appeals that have already been dispatched?
sql> select *
from tasks
where appeal_id in (
  select appeal_id
  from tasks
  where status = 'completed'
    and type = 'RootTask'
    and appeal_type = 'Appeal'
)
and appeal_type = 'Appeal'
and status not in ('completed', 'cancelled');
# https://caseflow-looker.va.gov/sql/fj2kpdbvbtrkqh
# 18 total!

# Let's filter out the non-blocking mail tasks.
sql> select *
from tasks
where appeal_id in (
  select appeal_id
  from tasks
  where status = 'completed'
    and type = 'RootTask'
    and appeal_type = 'Appeal'
)
  and appeal_type = 'Appeal'
  and type not in ('EvidenceOrArgumentMailTask')
  and status not in ('completed', 'cancelled');
# https://caseflow-looker.va.gov/sql/v9k2bdfxftft6q
# Down to 12
# Let's take a look at one of these appeals
rails c> appeal = Appeal.find(2042)
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
# [[142636, nil, "RootTask", "completed"],
       [142637, 142636, "TrackVeteranTask", "completed"],
       [142638, 142636, "DistributionTask", "completed"],
       [142639, 142636, "TranslationTask", "on_hold"],
           [158178, 142639, "TranslationTask", "assigned"],
       [142651, 142636, "JudgeDecisionReviewTask", "completed"],
           [146136, 142651, "AttorneyTask", "completed"],
       [202125, 142636, "BvaDispatchTask", "completed"],
           [202126, 202125, "BvaDispatchTask", "completed"]]
# TranslationTasks ARE blocking.
# Are TranslationTasks typically children of RootTasks? Nope!
  - Nope!
  - Looks like we create them from the "SEND_TO_TRANSLATION" task action as well.
  - We've created 5 TranslationTasks this way, so far and 45 from the RootTask.
  - https://caseflow-looker.va.gov/sql/5cfqv4wzwhctzh
  - But that doesn't appear to be the problem with this bad boy.

# It looks like the TranslationTask was created BEFORE the JudgeTask.
# Did we distribute to the judge without first checking if we had blocking tasks?
# Does the code allow us to do this?
# Which docket was this appeal on?
rails c> appeal.docket_type
# "direct_review"
# Money spot in the code: Docket::docket_appeals -> 
#   Appeal.active.where(docket_type: docket_type)
# Does `Appeal.active` correctly handle the case where a translation task exists for
# an appeal?
# We also check that appeals are `Appeal.ready_for_distribution`. Is this incorrect?
# We take into account that there may be MailTasks that have been created for an appeal
# that SHOULD block distribution.
# Are we doing the same for any other types of tasks that might be attached to the
# RootTask?
# What else might those be?
sql> select count(*)
, type
from tasks
where parent_id in (
  select id
  from tasks
  where type = 'RootTask'
)
group by 2
order by 1 desc;
# https://caseflow-looker.va.gov/sql/4t4zzs7zh5s7rf
# There are a bunch!
# Task types that have a RootTask parent that SHOULD block distribution and are
# currently NOT blocking distribution given how the code is written:
# * HearingTask
# * InformalHearingPresentationTask
# * TranslationTask
# Only these three are incorrectly handled. Should we add them to the list?
# Perhaps we should default to blocking distribution if there are any blocking
# DistributionTasks open on the RootTask...

# For this particular case, why didn't we care about the TranslationTask?
# Why was this TranslationTask created in the first place?
# - This appeal originated from somewhere where we automatically create a TranslationTask
#   because there is a high likelihood that some documents in the file need to be
#   translated.
# Why was this case decided and dispatched?
# - Probably because there were no documents that needed to be translated, or the
#   translation communication happened over email and did not use the TranslationTask.
# Let's cancel this particulat TranslationTask, and then revisit if these tasks should
# block distribution.
rails c> task = Task.find(158178)
rails c> task.update!(status: Constants.TASK_STATUSES.cancelled, instructions: [task.instructions, "Cancelling task because case has been decided and distributed"].flatten)
# Did that update change anything in the task tree it should not have?
rails c> pp appeal.reload.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
# Parent org task was correctly marked as complete.

# Why didn't RootTask cancel all children tasks when it was completed?
# Because it only cancels TrackVeteran Tasks. Should it also cancel TranslationTasks?

# We're good to go on this one but still have plenty of work to do on the other appeals!

Open questions to investigate further:

• RootTask cancels all child TrackVeteranTasks when it completes. Should it also cancel TranslationTasks?
• Should tasks other than blocking MailTasks (HearingTask, InformalHearingPresentationTask, and TranslationTask, in particular) prevent case distribution?
• What happened with the remaining 7 AMA appeals that have active tasks? (https://caseflow-looker.va.gov/sql/xt4n9rdt657hj8)
• What is going on with all of the Legacy Appeals with active tasks?

[lowellrex]

Peeling off the next dispatched AMA appeal that has active tasks and figure out what is going on.

  rails c> task = Task.find(893)
  rails c> appeal = task.appeal
  rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
  # [[892, nil, "RootTask", "completed", "Organization"],
         [893, 892, "InformalHearingPresentationTask", "in_progress", "Organization"],
     [49714, 892, "DistributionTask", "completed", "Organization"],
         [49715, 49714, "InformalHearingPresentationTask", "completed", "Organization"],
     [126574, 892, "TrackVeteranTask", "completed", "Organization"],
     [133343, 892, "JudgeDecisionReviewTask", "completed", "User"],
         [138570, 133343, "AttorneyTask", "completed", "User"],
     [147479, 892, "BvaDispatchTask", "completed", "Organization"],
         [147480, 147479, "BvaDispatchTask", "completed", "User"]]
  # IHP task is the child of the RootTask. We created 2 IHP tasks... why?
  rails c> pp appeal.tasks.where(type: InformalHearingPresentationTask.name).pluck(:assigned_to_type, :assigned_to_id, :created_at, :status, :closed_at)
  # [["Organization",
      8,
      Thu, 14 Feb 2019 23:06:56 UTC +00:00,
      "completed",
      Tue, 05 Mar 2019 15:40:02 UTC +00:00],
     ["Organization",
      14,
      Tue, 30 Oct 2018 11:11:23 UTC +00:00,
      "in_progress",
      nil]]
  # VFW's (org 14) IHP task was opened in October and never completed.
  # Who represents this appeal?
  rails c> appeal.representatives
  # Only DAV (org 8)
  # VFW does not need to write an IHP since they are not the representative, let's cancel
  # that task.
  rails c> task.update!(status: Constants.TASK_STATUSES.cancelled)

Only 5 dispatched AMA appeals with incomplete tasks remaining.

[lowellrex]

4 dispatched AMA appeals with incomplete tasks remaining.

rails c> task = Task.find(860)
rails c> appeal = task.appeal
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[119, nil, "RootTask", "completed", "Organization"],
       [563, 119, "JudgeDecisionReviewTask", "completed", "User"],
           [659, 563, "AttorneyTask", "completed", "User"],
       [805, 119, "QualityReviewTask", "completed", "Organization"],
           [859, 805, "GenericTask", "assigned", "User"],
           [860, 805, "GenericTask", "assigned", "User"],
       [861, 119, "BvaDispatchTask", "completed", "Organization"],
           [862, 861, "BvaDispatchTask", "completed", "User"]]
# It looks like the two child tasks of the QR org task are still open...
rails c> parent_task = Task.find(805)
# Was closed on 25 October 2018.
# Are the child GenericTasks assigned to members of the QR team?
rails c> parent_task.children.map(&:assigned_to).uniq.first.organizations
# Both assigned to a single attorney who is on the QR team. These were
# QR tasks before we created QR tasks assigned to inidividuals.
# Let's cancel them both.
rails c> parent_task.children.each { |t| t.update!(status: Constants.TASK_STATUSES.cancelled) }
# How'd we do?
rails c> pp appeal.reload.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[119, nil, "RootTask", "completed", "Organization"],
 [563, 119, "JudgeDecisionReviewTask", "completed", "User"],
 [659, 563, "AttorneyTask", "completed", "User"],
 [805, 119, "QualityReviewTask", "completed", "Organization"],
 [859, 805, "GenericTask", "cancelled", "User"],
 [860, 805, "GenericTask", "cancelled", "User"],
 [861, 119, "BvaDispatchTask", "completed", "Organization"],
 [862, 861, "BvaDispatchTask", "completed", "User"]]
# Excellent!

[lowellrex]

Down to 3!

rails c> task = Task.find(853)
rails c> appeal = task.appeal
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[178, nil, "RootTask", "completed", "Organization"],
 [556, 178, "JudgeDecisionReviewTask", "completed", "User"],
 [710, 556, "AttorneyTask", "completed", "User"],
 [813, 178, "QualityReviewTask", "completed", "Organization"],
 [853, 813, "GenericTask", "in_progress", "User"],
 [863, 178, "BvaDispatchTask", "completed", "Organization"],
 [864, 863, "BvaDispatchTask", "completed", "User"]]
# Looks like another instance of QR task before we had a QR task.
rails c> task.assigned_to.organizations
# Yup! The assignee is an attorney on the QR team. Cancelling this task.
rails c> task.update!(status: Constants.TASK_STATUSES.cancelled)

[lowellrex]

Two QR tasks brings us down to 1 dispatched AMA appeal with incomplete tasks remaining!

rails c> task = Task.find(854)
rails c> appeal = task.appeal
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[106, nil, "RootTask", "completed", "Organization"],
       [584, 106, "JudgeDecisionReviewTask", "completed", "User"],
           [693, 584, "AttorneyTask", "completed", "User"],
       [815, 106, "QualityReviewTask", "completed", "Organization"],
           [854, 815, "GenericTask", "assigned", "User"],
       [865, 106, "BvaDispatchTask", "completed", "Organization"],
           [866, 865, "BvaDispatchTask", "completed", "User"]]
# Looks like another instance of QR task before we had a QR task.
rails c> task.assigned_to.organizations
# Yup! The assignee is an attorney on the QR team. Cancelling this task.
rails c> task.update!(status: Constants.TASK_STATUSES.cancelled)

rails c> task = Task.find(855)
rails c> appeal = task.appeal
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[65, nil, "RootTask", "completed", "Organization"],
       [589, 65, "JudgeDecisionReviewTask", "completed", "User"],
           [664, 589, "AttorneyTask", "completed", "User"],
       [817, 65, "QualityReviewTask", "completed", "Organization"],
           [855, 817, "GenericTask", "assigned", "User"],
       [867, 65, "BvaDispatchTask", "completed", "Organization"],
           [868, 867, "BvaDispatchTask", "completed", "User"]]
# Looks like another instance of QR task before we had a QR task.
rails c> task.assigned_to.organizations
# Yup! The assignee is an attorney on the QR team. Cancelling this task.
rails c> task.update!(status: Constants.TASK_STATUSES.cancelled)

[lowellrex]

The lone remaining dispatched AMA appeal with an open task is for an appeal with a BoardGrantEffectuationTask. Asking the intake experts on what we expect from this situation.

rails c> task = Task.find(163504)
rails c> appeal = task.appeal
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[143404, nil, "RootTask", "completed", "Organization"],
       [143405, 143404, "DistributionTask", "completed", "Organization"],
       [144992, 143404, "JudgeDecisionReviewTask", "completed", "User"],
           [146550, 144992, "AttorneyTask", "completed", "User"],
       [148937, 143404, "AodMotionMailTask", "completed", "Organization"],
           [148938, 148937, "AodMotionMailTask", "completed", "Organization"],
       [154690, 143404, "BvaDispatchTask", "completed", "Organization"],
           [154691, 154690, "BvaDispatchTask", "completed", "User"],
   [163504, nil, "BoardGrantEffectuationTask", "assigned", "Organization"]]
# No parent! How did that happen?!
rails c> BoardGrantEffectuationTask.count
# 1
# We've only created one of these things... what are they?

Moving on to looking at Legacy Appeals now.

[lowellrex]

We have 102 tasks attached to dispatched legacy appeals:

# How can we write a query that identifies dispatched legacy appeals with open tasks?

# https://caseflow-looker.va.gov/sql/d5gwykj9vbqftk
# select count(*)
# , type
# from tasks
# where appeal_type = 'LegacyAppeal'
#   and status not in ('completed', 'cancelled')
#   and appeal_id in (
#     select id
#     from legacy_appeals
#     where dispatched_to_station is not null
# )
# group by 2
# order by 1 desc;
# Lots of RootTasks and TrackVeteranTasks. Let's come back to those later.
# Let's write a ticket to close the RootTask and TrackVeteranTasks wheneve we dispatch
# a LegacyAppeal.

# Let's invert this and confirm that this is a good indication that the legacy appeal
# has truly been dispatched from the Board.
# https://caseflow-looker.va.gov/sql/bhcz5tkpqqhhyn
# select count(*)
# from legacy_appeals
# where id in (
#   select appeal_id
#   from tasks
#   where appeal_type = 'LegacyAppeal'
#     and type not in ('RootTask', 'TrackVeteranTask')
#     and status not in ('completed', 'cancelled')
# )
#   and dispatched_to_station is not null;
rails c> query_string = "select * from legacy_appeals where id in ( select appeal_id from tasks where appeal_type = 'LegacyAppeal' and type not in ('RootTask', 'TrackVeteranTask') and status not in ('completed', 'cancelled') ) and dispatched_to_station is not null;"
rails c> dispatched_legacy_appeals_with_active_tasks = LegacyAppeal.find_by_sql(query_string)
rails c> dispatched_legacy_appeals_with_active_tasks.count
# 57
# Have all of these been dispatched?
rails c> legacy_appeals_not_actually_dispatched = dispatched_legacy_appeals_with_active_tasks.reject(&:active?)
# 8
# So it's not a perfect match.
# Let's filter those out of the set of dispatched appeals we have and look at those tasks.
rails c> dispatched_legacy_appeal_ids = dispatched_legacy_appeals_with_active_tasks.pluck(:id) - legacy_appeals_not_actually_dispatched.pluck(:id)
rails c> dispatched_legacy_appeal_ids.count
# 49
# Perfect. Now let's get tasks that are attached to these appeals
rails c> tasks = Task.active.where(appeal_type: LegacyAppeal.name, appeal_id: dispatched_legacy_appeal_ids).where.not(type: [RootTask.name, TrackVeteranTask.name])
rails c> tasks.count
# 102
rails c> tasks.pluck(:id).sort
# [832, 1547, 4685, 4686, 5119, 7144, 8391, 12925, 12926, 15420, 15789, 17207, 18532, 18533, 20183, 24358, 26315, 30848, 31280, 31281, 31803, 31805, 31807, 43628, 43629, 46690, 46691, 52712, 67816, 72947, 74936, 78981, 78982, 110058, 110059, 111362, 111363, 123453, 123488, 123524, 123769, 123866, 123890, 123907, 127236, 127237, 128500, 128501, 131235, 131236, 131325, 131326, 139090, 139091, 145982, 145983, 145993, 145994, 146165, 146166, 147264, 147265, 150113, 150114, 151315, 152065, 152066, 152067, 152107, 152191, 152201, 152285, 152330, 152346, 152378, 158513, 158514, 159581, 159582, 159849, 159850, 164226, 164227, 167457, 167458, 167762, 167763, 169506, 169507, 173253, 173254, 175103, 179641, 179642, 184081, 191040, 191727, 194547, 194548, 198104, 203090, 205616]

[lowellrex]

• [x] Write a PR to only update VACOLS location code if the location code is Caseflow (#10853).
• [ ] Let's let the person who is assigned this task that they need to complete the task in Caseflow after we have fixed the re-charging location issue.

# Let's take a look at the first open task associated with a dispatched legacy appeal.
rails c> task = Task.find(832)
rails c> appeal = task.appeal
rails c> pp appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status, :assigned_to_type)
# [[1547, nil, "ColocatedTask", "on_hold", "Organization"],
       [832, 1547, "ColocatedTask", "in_progress", "User"],
   [1556, nil, "ColocatedTask", "completed", "Organization"],
       [674, 1556, "ColocatedTask", "completed", "User"],
   [10366, nil, "RootTask", "assigned", "Organization"]]
rails c> task.instructions
# Looking at the instructions it appears as if this task was actually completed
rails c> task.updated_at
# Mon, 25 Feb 2019 18:58:43 UTC +00:00
# Hasn't been touched in 3 months. This looks like the ColocatedTask just got left behind.
# We can't safely close this because we will update the case's location in VACOLS
rails c> appeal.location_code
# "98"

[lowellrex]

@msj0nes Are folks still seeing these issues? If so can we reach out to (or as the attorney to reach out to) the VLJ support staff working on the task have them mark the task complete if it has been completed?

[laurjpeterson]

@lowellrex - Corey emailed me/Jennifer White about VLJ Support Staff still seeing old cases in their queues earlier this week, but that might be outdated. I just looked at a few of Randy's old cases. I don't think he has any more legacy cases that had already been dispatched. Would it be useful for me to ask Corey/Randy/other VLJ Support Staff if they are seeing already dispatched cases still in their individual queues?

[laurjpeterson]

If it's helpful, I can tell the first one in the table Martina posted earlier is still having the issue:

CSS ID | Case Details URL | Status
-- | -- | --
VACOULLERJ | https://appeals.cf.ds.va.gov/queue/appeals/2649463 | Still in attorney's On Hold queue, though Case Timeline says dispatched from BVA 1/08/2019 (and I can see the decision doc in Reader 1/8/2019 as well)

[lowellrex]

It appears as if the appeal above (VACOLS ID: 2649463) has been remanded. The data is in the correct state, but maybe Caseflow is not behaving properly (we can write a ticket to address this and have Caseflow acknowledge remanded cases as closed). Either way, the open task is a ColocatedTask that is assigned to Tina Hunter so we can reach out Ms Hunter to see if she has completed work on the case and can mark the task complete.

  rails c> appeal = LegacyAppeal.find_by(vacols_id: "2649463")
  rails c> appeal.decided_by_bva?
  # false
  # Is this returning incorrectly? Should this really be reporting as having been
  # decided by the Board?
  rails c> appeal.status
  # "Remand"
  # We can still have the VLJ support staff complete the task though:
  rails c> appeal.tasks.active.where.not(status: Constants.TASK_STATUSES.on_hold).where.not(type: RootTask.name).count
  # 1
  rails c> appeal.tasks.active.where.not(status: Constants.TASK_STATUSES.on_hold).where.not(type: RootTask.name).first.assigned_to
  # Tina Hunter

[laurjpeterson]

LP will look again at the cases Martina posted and post what they would need to ask of other users to complete, so those tasks are no longer on hold.

[laurjpeterson]

1. Case: https://appeals.cf.ds.va.gov/queue/appeals/2649463
   CSS ID: VACOULLERJ
   RESOLVED!

2. Case: https://appeals.cf.ds.va.gov/queue/appeals/6fe29e4a-e3c6-4cfb-a2e6-d1a769257efc |
   CSS ID: vacomillee
   RESOLVED!

3. Case: https://appeals.cf.ds.va.gov/queue/appeals/3800101
   CSS ID: BVALCROHE
   Situation: Same as #4 below. It's not in BVALCROHE's queue. Unknown what the open task is. However, I don't think it's causing any user issues anymore

4. Case: https://appeals.cf.ds.va.gov/queue/appeals/3864391
   Attorney: bvaNRippel
   Situation: This is not currently in either BVARIPPEL's assigned nor on hold queue. It also says that the case has been dispatched. It looks like there is still an open task, but I can't see what it is either in Caseflow prod or in Looker. I think this open task needs to be canceled. However, I don't think it's causing any user issues anymore
   
   

[lowellrex]

Marked both of the root tasks for these cases as completed. Does any other work remain on this ticket or can we close it out?

  rails c> appeal = LegacyAppeal.find_by(vacols_id: 3800101)
  rails c> appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
  # [[13265, nil, "RootTask", "assigned"],
     [19326, nil, "ColocatedTask", "completed"],
     [19327, 19326, "ColocatedTask", "completed"]]
  # Appeal has been dispatched. Closing the RootTask.
  rails c> Task.find(13265).update!(status: Constants.TASK_STATUSES.completed)

  rails c> appeal = LegacyAppeal.find_by(vacols_id: 3864391)
  rails c> appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
  # [[33557, nil, "RootTask", "assigned"]]
  # Just a single root task. Completing this as well since the decision has
  # been dispatched.
  rails c> Task.find(33557).update!(status: Constants.TASK_STATUSES.completed)

[msj0nes]

@lowellrex I have one more stuck one https://appeals.cf.ds.va.gov/queue/appeals/3896771. Still shows 'On Hold' in the attorney's queue

[lowellrex]

Legacy Appeal with VACOLS ID 3896771 is showing up in the attorney's on hold tab because they created an admin task that a member of the VLJ support staff has not yet completed.

  rails c> appeal = LegacyAppeal.find_by(vacols_id: 3896771)
  rails c> appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :status)
  # [[35357, nil, "RootTask", "assigned"],
     [46490, nil, "ColocatedTask", "on_hold"],
     [46491, 46490, "ColocatedTask", "in_progress"]]
  rails c> Task.find(46491).assigned_to
  # RANDY SEAY

I don't know if this task still needs to be completed (since the decision for this appeal has already been dispatched), but I propose we leave that decision to the VLJ support staff. If the attorney wants this task to disappear from their on hold tab they should reach out to Randy Seay. The attorney should also be able to see who has an active task for that appeal by clicking through to the case details page and looking at the information displayed at the top of the page in what we call the Task Snapshot area.

[msj0nes]

@lowellrex attorney is requesting the task be closed and it should automatically close because there is no case. VLJ support told the attorney this and said there is nothing they can do. Can we just close it? Shes the only attorney to come forward since I notified users the hold issue is fixed.

There may be a few of these. As the issue was discussed on the VLJ Support side in ticket https://github.com/department-of-veterans-affairs/appeals-support/issues/5071 where VLJ support is saying they completed some tasks and they got dispatched but still show as tasks to be completed.

[lowellrex]

If what they are asking to do is available to do in Caseflow then I believe it should be done in Caseflow (to reduce the burden on the development team and build their familiarity with Caseflow so they can be self sufficient if the development team is not available). If what they are asking to do is not available in Caseflow then we should create a ticket to develop some way for them to accomplish what it is they would like to accomplish.

However, I believe what they are asking is available in Caseflow by selecting either the "Cancel task" or the "Send back to attorney" options in the actions dropdown in the Task Snapshot on https://appeals.cf.ds.va.gov/queue/appeals/3896771. @laurjpeterson can you masquerade as Randy at some point this week to verify that those options are available to him for that appeal?

[msj0nes]

These are the options available to Randy @lowell. I cancelled using Randy and the case is now gone from Attorney Queue.

[lowellrex]

Perfect! Thanks @msj0nes !

[lowellrex]

Is there any remaining work to be done on this ticket or can we close it out?

[msj0nes]

@lowell I think its safe to close.