Write a tech spec to allow tasks to block dispatch

[hschallhorn]

According to feedback from the board, some tasks should block a caseflow case from being dispatched. These tasks will (eventually) be:

• CongressionalInterestMailTask
• FoiaRequestMailTask
• PrivacyActRequestMailTask
• PrivacyComplaintMailTask
• FoiaColocatedTask
• FoiaTask
• PrivacyActTask

We do not currently have logic to allow for tasks to block dispatch, only for tasks to block distribution.

AC

• Tech spec is written on how to allow tasks to block dispatch

[hschallhorn]

@araposo-tistatech Do we know if these tasks should block a case from being assigned to dispatch, or blocked from actually being dispatched/outcoded

[araposo-tistatech]

@hschallhorn these tasks should block the case from actually being dispatched. The issue with that is it will cause an increase in dispatch's queue of cases that cannot be worked or moved.

[hschallhorn]

Timeboxing to a 3!

[lomky]

Notes from spitballing with @hschallhorn!

AMA we can use similar logic to blocking distribution. Legacy... not sure we can do this in caseflow? Might be a matter of the VACOLS status?

AMA
Is there some way we can utilize 'children of root tasks' as representing the main flow we're at, and block there?
Consider using concerns, 'Blockable' for Dispatch & Distribution, or 'Blockerable' (:thinking:) for specific mail tasks.
Should things that block Distribution block Distribution & and beyond (i.e. also Decision review, dispatch) or just the actual distribution?

For things that block dispatch, should we instantiate the dispatch task when we create them? What are the implications for autoassign? How do we stop them from displaying to users when they're not actionable? Keep it from affecting the days waiting?
Alternately, when we create the Dispatch task, should we check for open blocker tasks and move those to be children of the dispatch task? Same questions re: display to users and days waiting.

[hschallhorn]

Kat and I briefly discussed this in pairing. Dumping some thoughts here in case neither of us are the ones who pick this up!

Relation to blocking Distribution

We already implement the concept of a mail task that blocks distribution. This is easy enough as every appeal is created with a distribution task.

Question: Do we want to similarly create a dispatch task for all appeals upon creation?
Pitfalls:

1. Who will this dispatch task be assigned to/reside? Don't want to fill up dispatch queue with tasks that are waiting to be ready to dispatch
2. Dispatch is an org that auto assigns tasks. Similarly do not want to fill up a dispatch user's queue with tasks that are not ready for them to work.

Optics of having an open dispatch task

Many users have complained about the confusing "pending dispatch" wording in case timeline for every case, regardless of whether or not that case is actually at dispatch. Will having an open dispatch task at any point in the appeals process be similarly confusing? Will we need to hide this task from users until it is ready to be worked?

[hschallhorn]

Notes from pairing!

• This should only apply to AMA appeals (legacy cases can be moved in vacols, even with blocking tasks)
• These tasks will block dispatch_instead_ of blocking distribution.

[ajspotts]

Closing this as discussion going forward should occur in #14661