mailing_filter

A mailing's recipients are defined by a domain: customers in a country, contacts with a tag, leads above a value. Building one takes a few minutes, and the same audience is usually mailed more than once, so Odoo lets you save a domain as a named favorite and reload it later.

This widget is where that happens. It renders as a normal relation picker for the saved filter, with two small icons beside it. One saves the mailing's current domain as a new favorite, asking for a name in a small dropdown. The other removes the loaded favorite from the mailing.

The removal is the more considered of the two. Clearing the favorite does not clear the audience: the widget writes the filter's domain into the mailing's own domain field first, so the recipients stay exactly as they were and only the link to the favorite is dropped.

Saved audiences are what turn email marketing from a series of one-offs into a repeatable programme. If rebuilding the recipient domain is a five minute job every time, people either skip segmentation or reuse a mailing by duplicating it, which drags old content along with the audience.

The behavior worth explaining to a marketing team is the removal semantics. Dropping a favorite keeps the audience, which is almost always what people mean; they want to stop tracking the favorite, not to mail everybody. If they genuinely want a different audience, the domain has to be edited afterwards.

The other thing to plan for is that this whole model changes in the next version. A single favorite per mailing becomes several dynamic lists, which is a better fit for how audiences are actually composed, and it means any process or training built around the current widget will need revisiting.

The core usage

<field name="mailing_filter_id" widget="mailing_filter"
       placeholder="Reload a favorite filter"
       options="{'no_create': 1, 'no_open': 1,
                  'domain_field': 'mailing_domain',
                  'model_field': 'mailing_model_id'}"
       readonly="state in ('sending', 'done')"/>

Creation and opening are disabled through inherited options, because filters are created through the save icon rather than the dropdown.

Relying on the defaults

<field name="mailing_filter_id" widget="mailing_filter"/>

Valid on the mailing model, whose domain and model fields match the defaults.

On another model

<field name="filter_id" widget="mailing_filter"
       options="{'domain_field': 'target_domain',
                  'model_field': 'target_model_id'}"/>

The source comment names marketing automation campaigns as the other intended model, which is why the field names are options rather than constants.

Saving is a direct record creation rather than a form. The widget reads the name typed into the dropdown, refuses an empty one with a notification and keeps the dropdown open by stopping the event, then creates a filter record carrying that name, the mailing's current domain and its model, and finally selects the new record in the field.

Removing is the more interesting half. It writes two things in one update: the field itself to false, and the domain field to the domain that was on the loaded filter. That ordering is what preserves the audience. Without it, dropping the favorite would leave the mailing with whatever domain it had before, which after a reload is usually nothing.

The save icon's availability is recalculated after every render, based on whether a filter is set, whether the input was emptied, whether the domain has diverged from the saved one and whether the field is currently being edited. That logic is documented in a comment in the source, which is unusual and useful.

The implementation detail worth flagging is how it finds its own controls. The icon state is applied by looking up elements with document-wide queries rather than through component references, and the name input is read the same way. That works because there is one of these on a mailing form, and it would not if there were two, which puts this widget in the same small family as a couple of others in core that reach into the document.

One more thing: the class extends the base component rather than the relation picker component, and rebuilds the picker's props itself. That is why its declared props copy the relation picker's props explicitly instead of inheriting them.

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.

The widget is deleted. There is no registration under this name on the development branch and the JavaScript file is gone, although the underlying filter model survives.

The concept changes shape. The mailing form replaces the single favorite with a many-to-many of what it now calls dynamic lists, rendered with a mailing-specific tags widget, and shows a recipient count beside it. The recipient domain itself moves to a savable domain widget.

So this is not a rename to follow but a redesign: one saved filter per mailing becomes several, composed together. Custom code reading the single favorite field should be reviewed before upgrading.