label_selection

label_selection is a one-job widget: take the current value of a selection field and render it as a colored label. The color comes from its single option, classes, a dictionary from selection keys to Bootstrap contextual color names. The template is a single span with badge text-bg- plus the resolved color; any value not in the map renders in primary, the source's hardcoded fallback.

Its defining property is what it lacks: an edit mode. Most display-leaning widgets at least switch to an input when the form is editable; this one's template has no second branch. Whether the view is readonly or not, the label is what you get, and the value can only change through other means, server logic, buttons, or another widget elsewhere in the view.

The text inside the label is the selection's display label run through Odoo's formatter, so it is translated and human readable, never the technical key.

Status columns are read a hundred times more often than they are edited. This widget optimizes exactly that ratio: color carries the state to a scanning eye faster than text, and the enforced readonly-ness makes it impossible to bump a document's state with a stray click in an editable list, a real hazard with clickable state widgets.

The palette is a governance tool if you are disciplined: green for done, yellow for pending, red for failed, consistently across every screen. Because each view declares its own classes map, that consistency is a convention you maintain, not something Odoo enforces, worth an internal style note when several people write views.

Payment acquirers are core's showcase: transaction states render with this widget so finance staff can scan hundreds of rows for the red ones. That pattern, big lists scanned for exceptions, is where the widget earns its keep.

Payment state column, core style

<field name="state" widget="label_selection"
       options="{'classes': {'draft': 'info', 'done': 'success', 'cancel': 'danger', 'error': 'danger'}}"/>

Minimal: color only the problem states

<field name="state" widget="label_selection"
       options="{'classes': {'failed': 'danger', 'pending': 'warning'}}"/>

Unmapped states (confirmed, done) fall back to the primary color; only the states worth noticing get their own.

Odoo has two readonly label widgets for selections and the choice confuses every implementer once.

Where the color comes from. This widget colors from its classes option, declared per view. The badge widget colors from decoration-* attributes on the field element, expressions evaluated against the record, which means badge can color on conditions beyond the field's own value.

Types. This widget accepts only selection fields; badge also takes many2one and char.

Failure modes. Here, an unmapped value silently renders primary. With badge, a decoration expression error breaks louder. Silent fallback is friendlier in production and easier to miss in review; check your map covers every selection key, including ones added later, a classic source of the mystery blue label.

Rule of thumb: coloring by the field's own value with a static map, use this widget; coloring by other fields or conditions, use badge.

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 option, the primary fallback and the registration are identical on the development branch; the component is ported to the new Owl props system (the default mapping moves inline, with no behavioral effect). The 18.0 and 19.0 files are byte-identical too, making this one of the most stable widgets in the set. We re-verify after release.