domain

A domain in Odoo is a filter expression, the bracketed condition list like [('state', '=', 'sale')] that powers every search, automation trigger and targeted mailing. Stored on a record, it is just a string in a char field. This widget replaces that string with the full visual builder: condition rows with field pickers and operators, and or grouping, a live count of matching records, and a button that opens the actual matching records in a dialog so users can eyeball what their filter caught.

Core leans on it wherever a business user defines "which records": automation rule triggers in base_automation, lead assignment rules in crm, mailing list filters in mass_mailing, loyalty rule conditions, stock reordering scopes. One widget is the difference between those features being admin friendly and being developer only.

The record count is the quiet hero here. A filter that looks right and matches 0 records, or 4 million, is the classic automation accident: the mass mailing that goes to nobody, the pricing rule that applies to everything. Surfacing "1,254 record(s)" next to the condition, with a click through to the list, catches those mistakes at authoring time instead of at 2 a.m.

For managers rolling out automations: treat the count as a required review step. The person writing the rule states the number they expect, the widget shows the number that is real, and the two get reconciled before activation. That one habit prevents most automation incidents we get called in for, and it costs nothing because the widget already computes the number.

Fixed model: filter contacts

<field name="partner_domain"
       widget="domain"
       options="{'model': 'res.partner'}"/>

Dynamic model read from another field

<field name="model_name" invisible="1"/>
<field name="filter_domain"
       widget="domain"
       options="{'model': 'model_name'}"/>

Because model_name is a field on the record, the builder retargets whenever its value changes. This is the base_automation pattern.

Expressions, dialog editing and a tighter count

<field name="assign_domain"
       widget="domain"
       options="{'model': 'crm.lead', 'allow_expressions': True, 'in_dialog': True, 'count_limit': 1000}"/>

With in_dialog, the inline builder is replaced by an edit button opening the selector in a dialog, which suits crowded forms.

How the count works. The widget calls search_count silently with a limit of count_limit + 1. If the result reaches the probe limit, it displays the capped count and flags it as limited, which is why huge datasets show 10000+ instead of hanging the form on a full count. The count button opens a single select, no create dialog of the matching records, and the counter refreshes when that dialog closes, because records can be edited from inside it.

What counts as an expression. Literals like [('active', '=', True)] evaluate client side. The moment the domain references non literals, user.id, context_today(), relative date math, the widget flags it. Without allow_expressions the field is marked invalid with the notification that the domain should not involve non literals; with it, you get a softer warning that evaluation might fail, because the client cannot know what the server will inject. The count in expression mode is computed against the evaluated form when possible.

Developer mode changes the contract. With debug on, the raw domain string becomes editable next to the builder. Edits there bypass the visual tree and are checked server side through /web/domain/validate when the record saves, setting the field invalid on failure rather than letting a broken domain through. The foldable option adds one more layer: the domain collapses into readable facet chips, loaded through the tree processor, with the builder a click away.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. What follows is read from the public development branch, which is unstable until feature freeze; we re-verify this page against the shipped release.

No option changes are visible. All five options survive with identical names and defaults, a rarity in this batch of pages. The visible movement is operational: the /web/domain/validate RPC becomes cached, so repeated validation of the same domain string stops hitting the server, and the field claims full width through an added w-100 class. Props declarations migrate to the new schema system without behavior change.

In short, domains built on 19 should carry to 20 untouched, and we will confirm that against the release build.