Business applications provide systems with records for business operations, but are also expected to support dynamic business rules that are specific to the organization use cases.
Carving these rules into custom addon modules can be inflexible and out of the reach of functional users. Automated actions triggered by event conditions can bridge this gap and provide a powerful tool to automate or enforce the organization procedures.
As an example, we will enforce a validation on Project tasks such that only the Project Manager can change Tasks to the Done stage.
To follow this recipe, you will need to have the Project Management app already installed. We also need to have the Developer Mode activated. If it's not, activate it in the Odoo About dialog.
To create an automated action with an event condition on tasks, follow these steps:
- In the Settings top menu, select the Technical | Automation | Automated Actions menu item, and press on the Create button.
- Fill out the basic information on the Automated Actions form:
- Rule Name: Validate Closing Tasks
- Related Document Model: Task
- Conditions tab |When to Run: On Update
- The
on updaterules allow you to set two record filters, before and after the update operation. On the Before Update Filter field text box, after the Select Records link, set a valid domain expression:[('stage_id.name', '!=', 'Done')]. On the Filter field text box, set the following domain:[('stage_id.name', '=', 'Done')], as shown in the following screenshot.
- On the Actions tab, under Server Actions to Run, click on Add an item, and on the list dialog, press on the Create button to create a new server action.
- Fill out the server action form with the following values and afterwards press on the Save button:
- Action Name: Validate Closing Tasks
- Base Model: Task
- Action To Do: Execute Python Code
- Python Code: Enter the following:
if user != obj.project_id.user_id: raise Warning('Only the Project Manager can close Tasks')
The following screenshot shows the entered values:
- Click on Save, to save the automated action and try it out:
- On a database with demo data and logged in as Administrator, go to the Project top menu and click on the E-Learning Integration project to open its task Kanban.
- Then try dragging one of the tasks into the Done stage column. Since this Project's Manager is user
Demoand we are working with the userAdministrator, our automated action should be triggered, and our warning message is blocking the change.
We start by giving a name to our automated actions and setting the Model it works with. For the type of action, we choose On Update, but the On Creation, On Creation & Update, On Deletion, and Based On Form Modification options are also possible.
Next, we should define the filters to determine when our action should be triggered. The On Update actions allow us to define two filters: one to check before and the other after the changes are made to the record. This can be used to express transitions: detect when a record changes from state A to state B. In our example, we want to trigger the action when a not-done task changes to the Done stage. The On Update action is the only one that allows for these two filters; the other actions types only allow for one filter.
It is important to note that our example condition will only work correctly for English language users. This is so because the Stage Name is a translatable field that can have different values for different languages. So, filters on the translatable fields should be avoided or used with care.
Finally, we create and add one (or more) server actions with whatever we want to be done when the automated action is triggered. In this case, we chose to demonstrate how to implement custom validation, making use of a Python code server action that uses the Warning exception to block the user changes.
In Chapter 5, Basic Server Side Development, we saw how to redefine the write() methods of a model to perform actions on record update. Automated actions on record update provide another way to achieve the same, with some benefits and drawbacks.
Among the benefits, it is easy to define an action which is triggered by the update of a stored computed field, which is tricky to do in pure code. It is also possible to define filters on records and have different rules for different records, or for records matching different conditions which can be expressed with search domains.
But automated actions can have disadvantages when compared to Python business logic code inside modules. As a concern, with poor planning this flexibility can rapidly grow into complex interactions, hard to maintain and debug. Also, the before and after write filter operations bring some overhead, so for performing sensitive actions this could be an issue.