Actions define the behavior of the system in response to user actions: login, action button, selection of an invoice, ...
Actions can be stored in the database or returned directly as dictionaries in e.g. button methods. All actions share two mandatory attributes:
A client can get actions in 4 forms:
The most common action type, used to present visualisations of a model through views: a window action defines a set of view types (and possibly specific views) for a model (and possibly specific record of the model).
Its fields are:
For instance, to open customers (partner with the customer flag set) with list and form views:
{
"type": "ir.actions.act_window",
"res_model": "res.partner",
"views": [[False, "tree"], [False, "form"]],
"domain": [["customer", "=", true]],
}
Or to open the form view of a specific product (obtained separately) in a new dialog:
{
"type": "ir.actions.act_window",
"res_model": "product.product",
"views": [[False, "form"]],
"res_id": a_product_id,
"target": "new",
}
In-database window actions have a few different fields which should be ignored by clients, mostly to use in composing the views list:
These are mostly used when defining actions from Data Files:
<record model="ir.actions.act_window" id="test_action">
<field name="name">A Test Action</field>
<field name="res_model">some.model</field>
<field name="view_mode">graph</field>
<field name="view_id" ref="my_specific_view"/>
</record>
will use the “my_specific_view” view even if that’s not the default view for the model.
The server-side composition of the views sequence is the following:
Allow opening a URL (website/web page) via an Odoo action. Can be customized via two fields:
{
"type": "ir.actions.act_url",
"url": "http://odoo.com",
"target": "self",
}
will replace the current content section by the Odoo home page.
Allow triggering complex server code from any valid action location. Only two fields are relevant to clients:
In-database records are significantly richer and can perform a number of specific or generic actions based on their state. Some fields (and corresponding behaviors) are shared between states:
Valid action types (state field) are extensible, the default types are:
The default and most flexible server action type, executes arbitrary Python code with the action’s evaluation context. Only uses one specific type-specific field:
<record model="ir.actions.server" id="print_instance">
<field name="name">Res Partner Server Action</field>
<field name="model_id" ref="model_res_partner"/>
<field name="code">
print self, object
</field>
</record>
Note
The code segment can define a variable called action, which will be returned to the client as the next action to execute:
<record model="ir.actions.server" id="print_instance">
<field name="name">Res Partner Server Action</field>
<field name="model_id" ref="model_res_partner"/>
<field name="code">
if object.some_condition():
action = {
"type": "ir.actions.act_window",
"view_mode": "form",
"res_model": object._name,
"res_id": object.id,
}
</field>
</record>
will ask the client to open a form for the record if it fullfils some condition
This tends to be the only action type created from data files, other types aside from multi are simpler than Python code to define from the UI, but not from data files.
Creates a new record, from scratch (via create()) or by copying an existing record (via copy())
the creation policy, one of:
fields to override when creating or copying the record. One2many with the fields:
Similar to object_create but alters an existing records instead of creating one
write policy, one of:
Executes multiple actions one after the other. Actions to execute are defined via the child_ids m2m. If sub-actions themselves return actions, the last one will be returned to the client as the multi’s own next action
Sends a signal to a workflow.
Indirection for directly returning an other action defined using action_id. Simply returns that action to the client for execution.
A number of keys are available in the evaluation context of or surrounding server actions:
Triggers the printing of a report
if set to True, the report is only generated once the first time it is requested, and re-printed from the stored report afterwards instead of being re-generated every time.
Can be used for reports which must only be generated once (e.g. for legal reasons)
Triggers an action implemented entirely in the client.
{
"type": "ir.actions.client",
"tag": "pos.ui"
}
tells the client to start the Point of Sale interface, the server has no idea how the POS interface works.
[1] | technically not an M2M: adds a sequence field and may be composed of just a view type, without a view id. |
odoo docs theme based on Bootstrap 3.2 documentation adapted to Sphinx output with branding and color changes.