radio_selection_with_filter

A selection field offers every value the model declares, always. That is usually right, and occasionally wrong: some choices only make sense for some records. A survey that already has answers cannot become a live session; a plan on a trial subscription cannot be the enterprise tier. Making the illegal choice visible and then rejecting it with an error is a poor experience.

This widget takes the ordinary radio rendering and filters it. It reads a second field on the same record, expects it to contain a collection of permitted values, and renders only the radio options whose value appears in that collection. Everything else disappears from the form.

Because it reads the allow-list from a field rather than from something fixed at render time, it is reactive. If the permitted set is a computed field, the visible radios update the moment the record changes in a way that changes the computation, without a page reload.

Hiding an impossible option is a better experience than validating it after the fact, and it removes a whole class of support question: why does Odoo let me pick this and then refuse it? On a configuration screen shown to non-experts, that difference is worth more than it looks.

The design decision worth thinking about is whether hiding is honest. A choice that disappears without explanation can read as a bug or as a missing feature. If the reason matters commercially, for example a tier the customer could unlock, hiding it entirely is the wrong pattern and a disabled option with a tooltip is better. Core uses this widget on survey type, where the constraints are structural rather than commercial.

The other point for anyone maintaining an Odoo 18 database: this widget changed how it is configured in Odoo 19. Views that were fine before will need editing, and nothing about the failure points at the widget, so it is worth checking during upgrade preparation rather than after go-live.

The core usage

<field name="allowed_survey_types" invisible="True"/>
<field name="survey_type" widget="radio_selection_with_filter"
       options="{'horizontal': True,
                  'allowed_selection_field': 'allowed_survey_types'}"
       invisible="not allowed_survey_types"/>

The allow-list field is loaded invisibly, and the whole radio group is hidden when nothing is allowed at all.

Vertical layout

<field name="tier" widget="radio_selection_with_filter"
       options="{'allowed_selection_field': 'allowed_tiers'}"/>

Without horizontal the base widget stacks the radios, exactly as the plain radio widget does.

What an Odoo 18 view looked like

<!-- Odoo 18 only: the allow-list came from context -->
<field name="survey_type" widget="radio_selection_with_filter"
       context="{'allowed_selection': ['survey', 'assessment']}"/>

On Odoo 19 this renders nothing useful: the context key is no longer read, and the required option is absent.

The class is fifteen lines: it extends RadioField, declares one extra prop, and overrides the items getter to filter the parent's list against the values held in the named field. Everything else, the rendering, the change handling, the layout option, belongs to the base radio widget.

Two deliberate narrowings sit in the descriptor. supportedTypes is set to ["selection"], dropping the many2one support the base radio widget has, which is consistent with the filter reading plain values. And the extractor spreads the base extractor before adding its own prop, so horizontal survives intact.

The version-to-version change is the part worth planning around. In Odoo 18 the prop was an array called allowed_selection, pulled from the field's context, and the filter compared against that fixed array. In Odoo 19 the prop became the name of a field, and the filter reads record.data[thatName] at render time. The behavior gained is reactivity; the cost is that every existing view has to change.

The failure mode is not friendly either. Without the option the required prop is missing, and if props validation is not active the filter reads record.data[undefined], which is undefined, and calling includes on it throws. Either way the form stops rendering rather than falling back to the unfiltered list.

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

The widget survives, its usage does not. The file is still registered on the development branch, with only the Owl props migration applied. But core's single usage moves away: the survey form now renders survey_type with the badge-style selection widget, passing the same allowed_selection_field option plus an icon mapping. That leaves this widget with no usages in core at all, which historically is how a widget gets deprecated.

If you use it, nothing breaks in Odoo 20. It is worth knowing that the maintained path is moving toward the badge widget.