kanban_color_picker

Open the three-dot menu on a project stage card, a maintenance team, or a survey and you find a small grid of colored dots. That grid is kanban_color_picker. It shows Odoo's standard record palette, twelve entries indexed 0 to 11 where 0 means no color, and writes the index of whatever the user clicks into an integer field on the record.

The widget itself is one of the smallest field components in the Odoo 19 web module: a template that loops over the shared ColorList palette, an active highlight on the current value, and a single click handler. Everything visual about the card, the colored left bar or tinted cover, is done elsewhere by the kanban card's own styling reading the same field. The picker only sets the number.

Color is the fastest grouping mechanism a kanban board has. Teams color project stages by risk, maintenance queues by criticality, recruitment stages by urgency, and from that point on the board communicates status before anyone reads a word. The picker is what makes this a user-level ability instead of a configuration request to IT.

The catch to plan for is that the palette maps to numbers, not meanings. Odoo will not stop one user meaning danger by red while another means marketing. If colors carry process meaning in your team, write the legend down somewhere visible, or generate the color from rules instead of hand-picking, which is a small customization on the same integer field.

Also worth knowing for training: a color picked here is saved instantly, on its own. Users do not need to save anything afterwards, and closing the menu does not undo the choice.

The core pattern: picker in the kanban card menu

<kanban>
  <templates>
    <t t-name="menu">
      <field name="color" widget="kanban_color_picker"/>
    </t>
  </templates>
</kanban>

The field sits inside the card's menu template, which is what puts it behind the three-dot dropdown.

The model side

color = fields.Integer(string="Color")  # 0 = no color, 1 to 11 = palette

The same integer drives card styling: Odoo's kanban card reads the field configured on the view to tint the card, so picker and card stay in sync by sharing the field.

Two behaviors read straight from the source separate this widget from its form-view cousin color_picker.

Saving is immediate and standalone. The click handler calls record.update({ [field]: index }, { save: true }). The record is saved right then, independent of anything else the user was doing. By contrast, color_picker, the form variant, only updates the record in memory and leaves saving to the normal form flow. Same palette, opposite persistence models, and the source is explicit about both.

Readonly means invisible, not disabled. The template's root node carries t-if="!props.readonly", so when the record is not editable the widget renders nothing whatsoever. If a menu section looks mysteriously empty for some users, check their write access on the model before debugging the view.

Each swatch is a real button carrying the color's translated name as both title and aria-label, so the picker is screen-reader friendly out of the box, and the current value's swatch gets an active class ring. There is no supportedTypes declaration either: nothing stops you pointing it at any field type, but everything in core points it at an integer, and the card styling expects exactly that.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We read this widget's file on the public development branch at the time of writing; the branch is unstable and moves until feature freeze, so we re-verify after release.

No functional changes: the palette, the instant save and the readonly behavior are identical. The only movement is the internal migration to the new Owl props declaration, which matters to JavaScript patches and not to any XML view.