Info |
---|
This solution is proposed by Patrick Delcroix. Feel free to comment, to challenge or improve it. |
Excerpt |
---|
There |
...
are several approaches to |
...
implementing workflows. The task based approach |
...
is one solution that does not require |
...
any entities schemas changes when the workflow changes. Principle |
...
of the task based workflowThe workflow should start based on a trigger |
...
. In Django, it could be |
...
managed by a signal listener part of a |
...
Workflow Implementation Module. When the signal is launch (the trigger can be a scheduled task, event from a module or user manual trigger through UI) then the |
...
listener could generate the task and start the entity workflow. Once the task is created:
|
...
|
...
Once the task is completed then based on the implementation workflow and the businessStatus resulting of the task execution the next action could be done (new task, entity update, etc … ) Task execution |
...
The task execution might required to validate the entity data or to add information |
...
. Therefore, the task page should “include“ the entity page |
...
. Nevertheless, an access mask should be applied to ensure that the task executioner won’t update part of model that he/she is not supposed to update. |
...
This mask should be provided by the |
...
BE based on the |
...
Workflow Implementation Module and will allow to limit the update possibility of fields in GUIs |
...
by limiting the visible fields in the GUI to show just what is needed to complete a specific task and reduce confusion for the user. |
...
No actions on entity |
...
would be available. Instead, |
...
the task action will be (example):
|