base_automation_trigger_selection

An automation rule fires on a trigger, and Odoo has around fifteen of them. Presented as a flat dropdown they are a wall of similar sounding phrases, and most of them do not apply to whatever model you just chose: there is no point offering to fire when the stage changes on a model with no stages.

This widget solves both problems. It groups the triggers under six headings in a deliberate order, from the everyday value changes at the top to the deprecated ones at the bottom. And it filters each group against the fields the chosen model actually has, dropping any trigger with nothing to watch.

The filtering is live. When you change the model on the rule, the widget fetches that model's fields from the server and recomputes the whole grouped list, so the dropdown always reflects the model in front of you.

Automation rules are the feature most likely to be configured by a business user rather than a developer, and the most likely to be configured wrongly. Every trigger removed from the list is a rule that cannot be created broken. That is worth more than documentation, because nobody reads documentation at the moment they are building a rule.

The deprecated group is the part worth understanding as a policy. Odoo does not delete old triggers, because existing rules use them, but it does not offer them either: the group only appears if the rule you are editing already uses one. So an old rule remains editable and visible, while a new rule cannot accidentally adopt a trigger that is on its way out.

The email group is the clearest example of model-aware filtering. Triggers based on messages only make sense on models with a chatter, and the widget knows that from a dependency the rule model exposes rather than from guesswork.

The core usage

<field name="trigger"
       widget="base_automation_trigger_selection"/>

No options. The widget reads the rule's target model itself and fetches that model's fields.

The companion field it depends on

# declared as a field dependency, so it is always loaded
model_is_mail_thread
# false hides the whole email events group

This one is declared properly rather than read by literal name, so it is loaded even when the view does not show it.

The six groups, in order

Values Updated      # stage, user, tag, state, priority, archive
Email Events        # message sent, message received
Timing Conditions   # on time, after creation, after update
Custom              # create, create or write, delete, on change
External            # webhook
Deprecated          # on write, hidden unless already in use

The order is fixed by a sequence number on each group, not by declaration order.

The filtering happens in two passes. First, each trigger value is looked up in the group table to find its heading. Triggers in the deprecated group are skipped unless the rule's current value is itself a deprecated one, and whole groups can be excluded by key, which is how the email group disappears on models without a chatter.

Second, each surviving trigger is checked against a per-trigger filter function. Those functions describe what kind of field the trigger needs, and the widget applies them to the target model's real field list. If nothing matches, the trigger is dropped. That is why the stage trigger vanishes on a model with no stage field, without anyone having to maintain a list of which models support which triggers.

The field list comes from a search on the field definition model, run inside a record observer. The observer remembers the last model it fetched for and only refetches when the model actually changes, which keeps typing elsewhere on the form from generating requests.

Odoo 19 made three changes here worth naming. The email events group is new, along with its dependency on whether the model is a message thread. The plain create trigger was added to the custom group. And the group objects renamed their label key, which matters to anyone patching the table.

The development branch adds something the current version lacks: a guard against a slow fetch. It stores the request rather than its result and stamps each observer run with an identifier, so a fetch for a model you have already moved away from cannot overwrite the list for the model you are now on. That is a real race in the current code, visible only if you change the model twice quickly on a slow connection.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

A race guard. The field fetch is restructured so that each run of the observer is stamped and the pending request is stored rather than awaited into a shared variable. The effect is that switching the rule's model twice in quick succession can no longer leave the dropdown showing triggers filtered for the wrong model.

Everything else is the props and state migration. The six groups, their order, the per-trigger filters and the email group's dependency are unchanged.