Automated Chasing
Due Date: a date when a particular task is the system is due.
Scheduled Events: automated events which are fired in relation to a Due Date.
Past Events: Scheduled events which is now historical data.
Chasing Events: a sub-type of Scheduled Event
Active Events: the queue of upcoming Scheduled Events a.k.a the list of scheduled events which are yet to be fired.
Scheduled Events Worker: the class which checks the Scheduled Event Queue and determines which Scheduled Events need to run.
(from an email by Sebastian Toomey)
A scheduled reminder can be in two top-level states:
- Pending (the date/time it’s scheduled to be sent is in the future)
- Processed (the date/time it was scheduled to be sent is in the past)
And then under each of these states:
- Pending
- On (the default, active state)
- Off (it’s been manually deactivated)
- Processed
- Sent
- Unsent (automatically deactivated by the system, e.g. the review was submitted before the scheduled send date)
- Unsent (was manually deactivated before the scheduled send date)
- Unsent (system error)
States for an event:
- Active: Scheduled Events which have not run yet
- Inactive: Scheduled Events which are turned off either by a user toggling the event off, or when a Due Date is rescheduled to a time which makes the event irrelevant.
- Processing: Scheduled Events currently being handled by the Scheduled Events Worker
- Completed: Scheduled Events which have been processed without errors
- Errored: Scheduled Events which could not be processed due to some system error
Epic link: APERTA-5469 - Automated Chasing Open
Here's a general proposal for the sequencing of this epic. This doesn't show all the tickets in the epic, but I think shows the tickets which comprise the epic's backbone.
Ben has already done most of this. We still need to add some configuration to the due dates ( APERTA-9685 - Review due date period default can be configured at workflow template level Closed ) but that's not a blocker for the subsequent steps
tickets:
APERTA-9692 - User can see events scheduled around a due date on the Reviewer Report card Closed
then
APERTA-9687 - Editing a due date reschedules associated events Closed
Create basic events data model in APERT-9692, in this ticket we only show a UI, so it's the best entry point to create a verifiable (because there's a UI) feature. When creating the model, we should consider the requirements APERT-9687 and APERTA-9688.
tickets:
APERTA-9688 - Send Reminders for review chasing Closed
and
APERTA-10712 - Create email templates for review reminder emails Closed
We'll do APERTA-9688 which fires off events. Since the events involve sending emails, we'll also need to create those email templates (APERTA-10712)
When designing the Automated Chasing, we decided to go with a bucket of scheduled events which a worker could work off. This made us lump all scheduled events—past, present, and future—into the same list. To work on this list, we have use scopes which identify parts of the scheduled event which satisfy different criteria at different times.
Through discussions and testing, we have identified a boundary within this list of scheduled events. This boundary demarcates the past events from the active events. Both queues change at different rates. The active events could be rescheduled when a due date is changed. The past events only serve as a historical record of the scheduled events on a particular due-date. Past events don't change very much. This informs a decoupling of Past Events from the normal events. There are some tate changes which come with this too.
This decoupled Past Event now serves as a pure historical. A past event may have one of "completed" or "errored" states. These states woulf not change. They exist as a record of how the event became a "Past Event".
This diagram shows the proposed change to the Scheduled Event (a.k.a active reminders).