property_selection

Odoo properties let a user define their own fields on a parent record, and a property of type selection carries its own list of values. Those values live in the parent's property definition, not on the record you are editing.

This widget bridges that gap. Point it at a char field, tell it which model, which properties field and which property, and it loads that property's selection values and offers them as choices.

Resolution happens through the field service:

async loadFieldInfos() {
    const propertiesDef = await this.fieldService.loadPropertyDefinitions(
        this.propertyModelName(),
        this.propertyFieldName()
    );
    const propertyDef = propertiesDef[this.propertyName()];
    return propertyDef?.selection ?? []
}

Note the optional chaining and the fallback. A property that cannot be found produces an empty list rather than an error, which is forgiving at runtime and unhelpful when you are debugging a blank field.

This is a niche widget with a specific job: letting one record choose from a vocabulary that a user defined somewhere else, without a developer creating a selection field for it.

The value is that the vocabulary stays under the user's control. The cost is the usual properties cost: the value is stored as text against a definition elsewhere, so reporting across records is awkward compared with a real selection or a related model.

Before reaching for it, it is worth asking whether the vocabulary is stable enough to deserve a real field. If the same list keeps being defined by hand, it has earned one.

All three options are mandatory:

<field name="chosen_value" widget="property_selection"
       options="{'property_model_name': 'project.project',
                 'property_field_name': 'task_properties_definition',
                 'property_name': 'my_property_key'}"/>

This fails prop validation rather than rendering an empty selection:

<!-- property_name is missing: the props declaration requires it -->
<field name="chosen_value" widget="property_selection"
       options="{'property_model_name': 'project.project',
                 'property_field_name': 'task_properties_definition'}"/>

Odoo 20 moves the web client to OWL 3, and the migration is close to total. We counted the files under addons/web/static/src/ on the 20.0 branch: 268 use useProps(), and only 3 still use the OWL 2 style static props.

This file uses neither. It imports a different API:

import { Component, props, asyncComputed, computed } from "@odoo/owl";

and uses it throughout:

selectedValue = computed(() => this.props.record.data[this.props.name]);
propertyName = computed(() => this.props.record.data[this.props.propertyName])
selectionItems = asyncComputed(() => this.loadFieldInfos(), { initial: [] })

We searched the whole web module for files importing a bare props from @odoo/owl. There is exactly one, and this is it.

Two things follow, and both matter if you are writing widgets for Odoo 20.

First, do not take this file as the pattern to copy. It is an outlier against 268 files, so whatever the reason for it, the convention the rest of core follows is useProps() with the t type builder. A widget written in this style will look wrong to anyone reading your module next to Odoo's.

Second, asyncComputed with { initial: [] } is genuinely useful and worth knowing about regardless. It gives a computed value that resolves asynchronously while rendering immediately with a placeholder. That is why this field shows an empty selection for a moment when the form opens, and why it does not need a loading state of its own.

The practical debugging consequence: a blank selection here has three possible causes that all look identical. The definitions are still loading, the property key does not exist in that definition, or the property exists but has no selection values. The optional chaining and the ?? [] fallback collapse all three into the same empty list.

Introduced in Odoo 20. Odoo 19 has no registration under this name.

It arrives alongside another new registration in the same area, properties_definition, which gives the properties definition editor a widget name it did not previously have. The properties system is being built out in Odoo 20 more broadly, while the older property_tags widget is unchanged.

Because the file uses OWL 3 APIs that do not exist in Odoo 19, it could not be backported without being rewritten.