Caseflow: Add validation checks where we expect only one open task

[yoomlam]

Motivated by https://github.com/department-of-veterans-affairs/dsva-vacols/issues/145, https://github.com/department-of-veterans-affairs/dsva-vacols/issues/174, and https://github.com/department-of-veterans-affairs/caseflow/issues/14307#issuecomment-690773618.

Description

Add validation checks where we expect only 1 open task for certain task types, specifically JudgeAssignTask.

Acceptance criteria

• [ ] only 1 open JudgeAssignTask should exist on an appeal at any time
• [ ] if needed, show error in UI when user attempts to create duplicate task
• [ ] create similar tickets for other task types; possibilities: HearingTask, AssignHearingDispositionTask, ChangeHearingDispositionTask, AttorneyTask, JudgeDecisionReview, QualityReviewTask, BvaDispatchTask. (Prioritize task types that are created/initiated by users (see https://github.com/department-of-veterans-affairs/dsva-vacols/issues/145) since tasks created by Caseflow is less likely to cause duplicate tasks.)

Background/context/resources

Refer to https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Tasks/tasktrees/descr/tasks-overview.md for identifying other task types.

Technical notes

Is there a Concern or otherwise reusable code we can add to these task types?

Reminder: ensure that task reassignment for the task type still works since the reassignment process is:

1. create a (duplicate) task but assign it to another user
2. cancel old task

[lomky]

_what is this chart?_

1 | 
2 | ||||||
3 | |||
5 | 
8 | 

Test flows of concern: reassignment, cancellation of JATask, cancellation of AttyTask.

UI error probably a no-op for this task - but keep an eye out

Why 1?

• Why 2?

• Small code changes

• very familiar area of the code base of us

Why 3?

• Add and update existing testing

[yoomlam]

Another reason to have this validation: https://github.com/department-of-veterans-affairs/dsva-vacols/issues/174

[jcq]

Communicated this verbally, but just to codify...

Since this appears to be something that isn't isolated to JudgeAssignTask, the logic for this should likely be implemented in the parent class and handle it generically based off of the name of the current task class. It can be up to the individual task classes to choose whether or not to actually use/implement the validation, however.

[GabbyTISTA]

Moved to https://vajira.max.gov/browse/CASEFLOW-1629

[yoomlam]

Given PR #16072, which uses a thread-local variable, would a simpler way be something like https://stackoverflow.com/questions/8881712/skip-certain-validation-method-in-model, where we set a non-DB attribute like skip_duplicate_validation? before calling task.save!? For consideration as we continue to implement solutions for the other task types.
I discussed this approach with @eileen-nava.