| Version | Date | Notes | By |
|---|---|---|---|
| 1.0 | 2023-06-20 | Initial release | ROB |
| 1.1 | 2025-05-07 | Small fixes | ROB |
The actions system allows for the encapsulation of a series of instructions that have to be done so that a higher level directive can be considered completed. For example when the frontend sends the high level instruction submit, then the submit action will itterate all variable instances that are dirty and save them, moving the process to the next task.
Essencially the complex code that saves the variables and moves the process forward is hidden behind the submit action making the controller more clean, and allowing the action to be reused in diferent contexts (not implemented, but in the future WeFlow™ scripts will be able to call these actions too).
Note: In the future it will be possible to chain directives, allowing for a set_variable_instance_attribute_to_value and submit actions to be sequentially executed with just one request. For now the set_variable_instance_attribute_to_value calls the submit action internaly, this is hardcoded and it is not possible to decouple them.
The system has a class called ActionHandler where the classes for each action are registered and matched to a directive (for example 'save' => new SaveAction($this)).
When the directive is triggered the execute() function is executed for that action, receiving the token process object that triggered it, as well as an associative array called $additionalParameters.
The class for that action must be created and must extend BaseAction or BaseSgiAction if the action interacts with other modules.
If the action should be available from the interface designer for use in a button, then the directive must be added to the getActions() function in the ActionHandler class.
This action itterates dirty variable instances (as sent by the frontend for example) and saves them.
This action does the same as the save action but also closes the current token process object and continues the bpmn processing.
Same as save, kept separate in case one of them needs to do something the other does not.
Equivalent to save, kept separate in case one of them needs to do something the other does not. A class will have to be created for this action if anything is diferent (this action calls the SaveAction class for now).
Triggers the standard cancel action. This cancels the entire token process.
Downloads the report defined as the target for this action (process holder revision must have that report defined).
This action sets a given attribute in a given variable to a specific (preset) value and submits.
Triggers the deletion of speficic variable instances.
Creates a new variable instance
Links to a process view (using the visualization system).
There is also the possibility to create actions that involve other modules, these actions are SGI actions. For now this part of the action system is underdeveloped but there is one action implemented.
Submits the task and opens the document revision set in the given variable instance / attribute in the edit revision page (it assumes the document revision is in elaboration).