dynamic_selection

dynamic_selection renders a selection field whose dropdown is filtered by the record itself. The widget reads a second field, named in its available_field option, expecting a char value of comma separated selection keys, and shows only the declared selection values whose keys are in that list.

The mechanism is deliberately primitive and deliberately powerful: the allowed list is ordinary field data. Compute it on the server from any logic you like, the document type, the country, the partner's tax regime, and the dropdown follows, record by record, live as dependencies change.

Core keeps this widget on a short leash: it exists in the account module and every core usage is an e-invoicing localization narrowing legal code lists, Greek myDATA classification codes, Romanian e-Transport, Spanish Veri*Factu, French PDP, to the subset valid for the current document. That is the problem it was built for: government code lists where the full list is huge and the valid subset depends on context.

Every compliance screen has the same failure mode: a dropdown of eighty legal codes of which seventy six are invalid for this document, and a user who picks a plausible wrong one. The rejection arrives days later from the tax platform, and the correction costs more than the invoice was worth.

Filtering at the point of entry is the cheapest fix that exists. The user cannot pick what the record does not allow; the error class disappears instead of being caught. This is why Odoo's own localization teams reach for this widget wherever a government publishes conditional code lists.

The pattern generalizes far beyond tax codes. Shipping service levels valid per carrier, contract clauses valid per contract type, quality checks valid per product family: anywhere you keep writing onchange warnings for invalid combinations, a computed allow list plus this widget removes the combination instead of warning about it.

The pattern, as documented in the source itself

The source file carries its own usage comment, worth reproducing almost verbatim. On the model:

the_available_field = fields.Char()  # comma separated allowed keys
the_selection_field = fields.Selection([...])

In the view:

<field name="the_available_field" column_invisible="1"/>
<field name="the_selection_field" widget="dynamic_selection"
       options="{'available_field': 'the_available_field'}"/>

The available field must be in the view (invisible is fine) so its value is loaded with the record.

Computing the allowed list

allowed_codes = fields.Char(compute="_compute_allowed_codes")

@api.depends("move_type")
def _compute_allowed_codes(self):
    for move in self:
        if move.move_type == "out_refund":
            move.allowed_codes = "credit_a,credit_b"
        else:
            move.allowed_codes = "invoice_a,invoice_b,invoice_c"

Change move_type and the dropdown reshapes immediately; no reload needed because the compute updates the record in the browser.

The widget overrides two getters from the base selection field, and the second explains its one surprising behavior.

options filters the declared selection through the allowed list: super.options.filter(x => availableOptions.includes(x[0])), where availableOptions is the char value split on commas (an empty or unset field yields an empty list, and an empty dropdown).

string, the readonly label, is where the base widget would crash: it looks up the current value in the filtered options and reads its label. When yesterday's stored value is outside today's allowed list, that lookup finds nothing, and the override's optional chaining turns the crash into an empty string. The comment above the override says exactly this: sometimes no options are available.

Two inherited behaviors are worth knowing. The base selection descriptor contributes placeholder_field, and its extractProps switches on autosave in kanban views, so a click on this widget in a kanban card writes the record immediately, same as the plain selection widget.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

No changes. The file is ported to the new Owl props system (the 18.0 and 19.0 files are byte-identical, and the development branch only swaps the props declaration style); the option, the filtering logic and the registration are untouched. We re-verify after release.