The workflow today is designed for the UI. To make it more general we need to adjust the database. This is meant to be the first draft for the changes necessary.
The predominant database tables for the workflow are ticket, task (reqtask), state, action and exit_condition. Each ticket and task has exactly one state. Each state has exactly one action but arbitrary many exit_conditions. For that reason table state_action can be dropped.
The state matrix will be replaced by directed graph approach. The states are the nodes, the exit_condition field next_state defines the edges (see db-diagram). Each state has a phase, to structure the workflow and make it more human readable.
The table action gets more fields. We introduce a status (see db-diagram). This enables the creation of a middleware-agent. This agent iterates through all tickets and tasks (without state completed). The fields start_time and max_time are used to determine timeout or failure. The field response may be used by the logic of exit_condition.
Open refinements
Should there be any restrictions for the task state regarding the ticket state
How do we store logic in exit_condition. As string, as reference to config file, as multiple predefined db-fields?
Do we need weight in exit_condition? Scenario would be that multiple exit_conditions match for one state
Are there more tables or fields to drop with the new approach
The workflow today is designed for the UI. To make it more general we need to adjust the database. This is meant to be the first draft for the changes necessary.
The predominant database tables for the workflow are ticket, task (reqtask), state, action and exit_condition. Each ticket and task has exactly one state. Each state has exactly one action but arbitrary many exit_conditions. For that reason table state_action can be dropped.
The state matrix will be replaced by directed graph approach. The states are the nodes, the exit_condition field next_state defines the edges (see db-diagram). Each state has a phase, to structure the workflow and make it more human readable.
The table action gets more fields. We introduce a status (see db-diagram). This enables the creation of a middleware-agent. This agent iterates through all tickets and tasks (without state completed). The fields start_time and max_time are used to determine timeout or failure. The field response may be used by the logic of exit_condition.
Open refinements