badge

Status reads faster as color than as text. The badge widget takes a field's display value, the label of a selection, the name of a many2one, a plain char, and wraps it in a rounded pill whose color you control per record.

The source resolves the color in a strict order. If the widget has a color_field option, it reads that integer from the record and applies the corresponding palette class, o_badge_color_0 through o_badge_color_11, the same palette tags use. Otherwise it walks the field's decoration-* attributes in order and applies the Bootstrap class of the first expression that evaluates true, text-bg-danger, text-bg-warning and friends. If nothing matches, the pill falls back to a neutral gray, class text-bg-300.

It is purely a display widget: readable everywhere, editable nowhere. Clicking a badge does nothing, which is exactly right for values that buttons and workflows are supposed to change.

Lists are where your team actually lives, and a status column of colored pills is scannable in a way text never is. Overdue in red, on-hold in yellow, done in green: a hundred-row list becomes a traffic report. The payoff is fewer missed exceptions, because the exceptional rows stop looking like every other row.

The discipline is a consistent color language. Red should mean the same severity on invoices, deliveries and tasks, or the colors stop carrying information. We keep a one-line legend per project, danger equals blocked or overdue, warning equals waiting on someone, success equals done, and apply it in every view we touch, because the decoration conditions live per view.

Badge versus full status widgets is also a cost decision: a badge is one attribute on an existing list column, no model change, no workflow, which makes it the cheapest visual win available on most screens.

Studio covers the widget itself; the color logic is XML.

1. Open the list or form in Studio and select the selection, many2one or char field.

2. In Properties, set Widget to Badge. The value now renders as a neutral pill.

Studio stops at the neutral pill. The two coloring mechanisms, decoration-* condition attributes on the field and the color_field option, are view-XML edits. They are one-line edits, shown below, and the usual moment teams hand a view to a developer for five minutes.

State-driven colors with decorations

<field name="state" widget="badge"
       decoration-danger="state == 'cancel'"
       decoration-warning="state == 'pending'"
       decoration-success="state == 'done'"/>

First matching condition sets the pill color; anything unmatched renders the neutral gray.

Color stored on the record

<field name="tag_id" widget="badge"
       options="{'color_field': 'tag_color'}"/>

The integer field tag_color (0 to 11) on the record picks the palette color, the same indexes the tags widget uses. Remember it overrides all decorations.

Full condition set including neutral

<field name="payment_state" widget="badge"
       decoration-success="payment_state == 'paid'"
       decoration-info="payment_state == 'in_payment'"
       decoration-muted="payment_state == 'not_paid'"/>

decoration-muted is legal here and maps to the same neutral gray as no match, verified in the source's explicit muted fallback.

Where the pill's color class comes from is worth thirty seconds, because it explains every styling question about this widget.

Decorations map to Bootstrap background classes. decoration-danger becomes text-bg-danger, and so on for warning, success, info, primary. The palette is your Bootstrap theme; restyle the theme and every badge follows.

The muted special case. Bootstrap has no text-bg-muted, so the source maps decoration-muted to text-bg-300, the same class used when nothing matches. Muted and unmatched are therefore visually identical, by design.

The color-field palette is Odoo's, not Bootstrap's. With color_field set, classes are o_badge_color_0 to o_badge_color_11, the eleven-color palette shared with tags. Index 0 renders the neutral style, which is why a tag with no color and a badge with no match look the same.

Evaluation order is declaration order. Decorations are checked in the order they appear on the field, first match wins. Put the most specific condition first when states overlap.

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.

Nothing changes for this widget. The development version of badge_field.js carries the same types, the same single color_field option, the same decoration-to-class mapping including the muted fallback. Only the internal component syntax moves to the new Owl props system, which affects JavaScript patches and nothing in XML. We re-verify once Odoo 20 ships.