field_selector

Configuration records frequently need to point at "some field of some model": the field a marketing card pulls its headline from, the field an automation writes, the attribute a report groups by. Storing that as free text invites typos; storing it as a relation to ir.model.fields is heavy and cannot express paths. The field_selector widget solves it with a char field wearing Odoo's ModelFieldSelector popover: the user browses actual field names with their labels and types, drills through relations with chevrons, and the widget stores the resulting dotted path as text.

Because the value is just a string like partner_id.country_id.code, it slots directly into everything Odoo evaluates paths with: mapped reads, domain construction, QWeb expressions. The picker guarantees the path was valid against the model at selection time.

This widget is a builder of no-code building blocks. Marketing cards let a marketer choose which field of the campaign's model appears on the shared image; automation-adjacent tooling lets an admin pick the field to watch or write. In each case the alternative was a text box and a support ticket when the path had a typo in it. If you are building configurable features for non-technical admins, template engines, export mappers, integration field maps, this is the input control that keeps your support queue short.

A worked example from our own practice: a client's custom document generator needed "which field holds the signatory's email" per document type. Swapping a char input for field_selector with only_searchable off and relations on eliminated an entire class of misconfigured templates, because invalid paths simply cannot be picked.

Pick a field of the current model

<field name="field_path" widget="field_selector"/>

Pick a field of a model chosen elsewhere on the form

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

This is the marketing_card pattern: model_name holds something like res.partner, and the picker browses that model. The referenced field must be loaded in the view, hence the invisible line.

Searchable fields only, no relation drilling

<field name="group_by_field"
       widget="field_selector"
       options="{'only_searchable': 'true', 'follow_relations': false}"/>

Right for paths that end up in domains or group-by clauses, where non-stored, non-searchable fields would fail at runtime.

Details from the source worth knowing before building on it.

The required flag reaches the popover. The component passes allowEmpty: !required, so a required field-selector refuses to store an empty path while an optional one offers a clear action. Debug mode also flows through: with developer mode on, the popover shows technical names and types it otherwise hides.

Properties are filtered twice. The component's filter hides the properties separator always, and hides property fields themselves unless allow_properties is truthy, which it is by default. Set it false when the stored path feeds machinery that cannot evaluate property paths.

Readonly renders the raw path. In readonly state the widget formats the char value as plain text, dotted path and all. If you want a human label shown to viewers, pair it with a computed description field; the widget does not resolve the path to labels outside the picker.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. These notes are read from the public development branch, which can change until feature freeze, and this page is re-verified after release.

Two option-level changes are visible. only_searchable is removed: the declared option and its filter logic are gone, so paths are no longer restrictable to searchable fields from the view. model becomes dual-natured: the master code resolves record.data[model] first and falls back to the option's literal value, so passing a real model name like res.partner will finally work, fixing the 19 quirk described above. Internally the prop is renamed from followRelations to followRelation, which only matters to JavaScript patches.