Stop changing JudgeTask type

[lowellrex]

When a judge at the Board receives an appeal to make a decision on, they take a sequence of steps in order to hand the appeal off to the next person in the lifetime of an appeal. The judge is required to sign a decision on the appeal and in order to do so they always assign the appeal to an attorney on their team to draft the decision, and then sign that decision once the attorney has finished drafting it. Judges also occasionally return decisions back to the attorney that drafted it.

We currently represent this in the task model as a task that is created with the type JudgeAssignTask and that type changes to JudgeReviewTask once the attorney has finished drafting their decision (in the language of the application, once the child AttorneyTask is completed).

Currently:

                                   |
-------------------------------    |    -------------------------------
                                   |
       Root task                   |           Root task
                                   |
-------------------------------    |    -------------------------------
         |                         |             |
         |                         |             |
         v                         |             v
     +-------------------+         |         +-------------------+
     |                   |         |         |                   |  # Task changes type
     |  JudgeAssignTask  |         |         |  JudgeReviewTask  |  # when child attorney
     |                   |         |         |                   |  # task is completed.
     +--------+----------+         |         +--------+----------+
              |                    |                  |    ^
              |                    |                  |    |
              v                    |                  v    |
         +--------------+          |             +--------------+
         |              |          |             |              |
         | AttorneyTask |          |             | AttorneyTask |
         |              |          |             |              |
         +--------------+          |             +--------------+
                                   |

We change the type of the judge task so that we can display a different set of available actions to the judge in the available actions dropdown menu. This is a little artificial because the task the judge has to complete has not actually changed even though the type has (the judge still has to deliver a signed decision). I think we should change the way the application represents the different steps in the process of a judge delivering a signed decision to better match the process.

Option 1: Use child AttorneyTask presence to determine actions

Currently we use the task type alone to determine which actions are available to the judge for a given appeal:

JudgeAssignTask

• Assign to attorney

JudgeReviewTask

• Ready for Dispatch
• (soon!) Return to attorney for corrections (or something similar)

Instead we could use the presence of a completed child attorney task to make that same determination:

No child AttorneyTask

• Assign to attorney

Completed child AttorneyTask

• Ready for Dispatch
• (soon!) Return to attorney for corrections (or something similar)

The task tree would look like the following in this case:

                                   |
-------------------------------    |    -------------------------------
                                   |
       Root task                   |           Root task
                                   |
-------------------------------    |    -------------------------------
         |                         |             |
         |                         |             |
         v                         |             v
     +-------------------+         |         +-------------------+
     |                   |         |         |                   |
     |     JudgeTask     |         |         |     JudgeTask     |
     |                   |         |         |                   |
     +--------+----------+         |         +--------+----------+
              |                    |                  |    ^
              |                    |                  |    |
              v                    |                  v    |
         +--------------+          |             +--------------+
         |              |          |             |              |
         | AttorneyTask |          |             | AttorneyTask |
         |              |          |             |              |
         +--------------+          |             +--------------+
                                   |

Option 2: Create separate assign and review tasks

If we want to retain the distinct JudgeAssignTask and JudgeReviewTasks we could create the latter when a judge tags an attorney to draft an appeal. The available actions would remain the same as they are now (determined by the task type), but the task tree would change to look like the following:

------------------------------------------------------------

     Root task

------------------------------------------------------------
          |      ^             |
          |      |             |
          v      |             v
   +-------------------+   +-------------------+
   |                   |   |                   |
   |  JudgeAssignTask  |   |  JudgeReviewTask  |
   |                   |   |                   |
   +-------------------+   +-------------------+
                                  |
    # JudgeAssignTask             |
    # marked as complete          v
    # when appeal assigned     +--------------+
    # to an attorney           |              |
                               | AttorneyTask |
                               |              |
                               +--------------+

Curious to hear thoughts on these approaches, whether you think this is actually a problem, or if there are alternative ways to address this concern.

[amprokop]

Agreed that the inconsistency is worth addressing.

Lean towards option 2 if these are the only options on offer, but I’m wondering if longer term we should consolidate and the JudgeAssignTask should just become an OrganizationTask, while JudgeReviewTask and AttorneyReviewTasks remain separate types.

That’s just a guess, and I know the LOE might be prohibitively high to tackle right now- but I’m curious if unification of Judge/Attorney tasks with other tasks is ultimately the path we want to go down.

[lowellrex]

I’m wondering if longer term we should consolidate and the JudgeAssignTask should just become an OrganizationTask

@amprokop I'm not sure I fully understand. Are you suggesting that we use the task tree described by approach 2 and set the assignee for the JudgeAssignTask to be the judge's JudgeTeam organization?

[amprokop]

Something like that, yeah. But it’s up to you, just a thought.

…

On Fri, Dec 21, 2018 at 10:38 Lowell Wood ***@***.***> wrote: I’m wondering if longer term we should consolidate and the JudgeAssignTask should just become an OrganizationTask @amprokop <https://github.com/amprokop> I'm not sure I fully understand. Are you suggesting that we use the task tree described by approach 2 and set the assignee for the JudgeAssignTask to be the judge's JudgeTeam organization? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8408 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADm0yz_ctCDRQXWAvpH9GlaJz3qhBjOjks5u7QBugaJpZM4Zd9wr> .

[anyakhvost]

Leaning towards option 2 because it would be easier to introduce new logic based on the judge task type.

[tomas-nava]

I'm encountering very similar issues with #8107 ... JudgeTasks that need to behave differently depending on whether their parent task is a QualityReviewTask. I'm sure we'll encounter more scenarios like this going forward.

With option 2 we can create a lot of purpose-built task classes that might be harder for a human to comprehend without a guide; with option 1 we can keep all the logic in one place, but it might get tangled.

[lpciferri]

@lowellrex - Since we now have JudgeDecisionReviewTask and JudgeAssignTask, is this still relevant?

[lowellrex]

@lowellrex - Since we now have JudgeDecisionReviewTask and JudgeAssignTask, is this still relevant?

Yes this is still relevant even though we have subclasses, since we are still doing it here:

caseflow/app/models/tasks/judge_assign_task.rb

Line 7 in 8d81363

update!(type: JudgeDecisionReviewTask.name)

[lowellrex]

LARGE. Be on the lookout for opportunities to break this up into smaller PRs as you get into working on it.

[lpciferri]

Moved to ready for dev pipeline because it's been estimated.