color

Odoo has two families of color widgets. The palette pickers, color_picker and kanban_color_picker, write an index into Odoo's fixed twelve-entry palette. This widget is the other family: a real color value, any of sixteen million, stored as a hex string in a plain char field.

The implementation, read from the Odoo 19 source, is refreshingly small: a div painted with the current value, with the browser's native <input type="color"> stretched invisibly across it. Clicking the swatch opens the operating system's own color picker, eyedropper and all where the platform provides one. When the field is empty, the swatch shows a transparent checker pattern instead of defaulting to black.

Core uses it where the exact color is the point: livechat button colors, website ribbon backgrounds, marketing card themes, product document tags.

This is the brand-consistency widget. Palette indexes are fine for internal kanban cards, but the moment a color leaves the backend, a chat bubble on your website, an event badge, a themed customer document, it must be your exact brand hex, not "Odoo purple, slot 5". Storing #1B4D3E in a char field is what makes that exact.

The operational detail to brief your team on is the save behavior. In list and kanban views the widget saves the record by itself the moment the picker closes, which is convenient for bulk-editing theme colors but means there is no discard step: the old value is gone. On forms it participates in the normal edit-then-save flow. Both behaviors come from one option you can override either way.

Standard usage on a char field

<field name="brand_color" widget="color"/>

The model side is just a char field:

brand_color = fields.Char(string="Brand Color", default="#875A7B")

List view without instant saving

<field name="brand_color"
       widget="color"
       options="{'autosave': False}"/>

Overrides the list-view default, so edited colors wait for the row's normal save.

Instant saving on a form

<field name="button_color"
       widget="color"
       options="{'autosave': True}"/>

The opposite override: the record saves as soon as the picker commits, useful for settings-style forms.

A few details from the component and template are worth having on record.

The commit moment is the input's change event. While the native picker is open, the swatch previews the color live, but the record update fires on change, which browsers emit when the picker is closed or the choice confirmed. With autosave on, that is also the save moment.

Empty means transparent, not black. The template paints the swatch with the stored value or, when empty, a transparent checker image. A native color input alone would display black for an empty value, which misleads users into thinking a color was chosen; the checker is the deliberate fix.

Readonly keeps the color visible. The input gets disabled and the container a disabled cursor, but the swatch still shows the value, so readonly lists remain scannable.

Validation is your job. The field is a plain char and the widget only ever writes what the native input produces, a 7-character hex string. Values arriving from imports or the API are not validated by the widget, so a malformed value simply paints nothing. Add a model constraint if the field feeds CSS.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. What follows is read from the widget's file on the public development branch, which remains unstable until feature freeze; we re-verify after release.

The autosave option is removed. The development version deletes the option, the prop and the view-type default logic; the update call always follows the standard record flow. In practice list and kanban edits stop saving instantly on their own and behave like every other inline-edited field, a small but real workflow change for teams used to instant color commits in list views. The component also migrates to the new Owl props syntax, which affects JavaScript patches only.