statusbar

Every Odoo record with a lifecycle announces it in the same place: the arrow-shaped stage strip in the form header. Quotation to Sales Order, Draft to Posted, New to Hired. That strip is this widget, rendering either a selection field's values or the records of a many2one to a stage model.

It is not just display. With clickable on, its default, clicking a stage writes the value and saves the record on the spot; the source calls record.update followed by record.save. That immediacy is what makes pipelines feel alive, and also what surprises teams whose automations fire the moment someone clicks.

On many2one stage fields the widget fetches the stages itself, and does one subtle thing verified in the source: the search domain is OR-ed with the currently selected stage's id, so a record sitting in a stage your domain excludes still displays honestly instead of showing blank.

The statusbar is your process, drawn on every record. When the stages match how work actually flows, nobody needs training to know what happens next; when they do not, users invent parallel tracking in spreadsheets and the ERP quietly stops being the source of truth.

Two design decisions matter more than any option. Keep the visible strip short, three to five stages, and fold the exceptional ones behind fold_field; a ten-arrow strip reads as bureaucracy. And decide deliberately whether clicking should move records: clickable defaults to on, which is right for sales pipelines and wrong for states that only buttons with checks should reach, like Posted on an invoice. Odoo itself renders account move states non-clickable for exactly that reason.

The immediate save is a process fact worth briefing: a click is a commit, not a suggestion. Stage-change automations, emails, timestamps, all fire right then.

Studio's Stages feature builds the standard setup on custom models.

1. Open your custom model's form in Studio.

2. Toggle Stages in the model properties. Studio creates the stage model, the many2one field, and places the statusbar in the header.

3. Add or reorder stages from the kanban or the stage model's list.

Studio stops at the standard setup. Making the bar read-only (clickable: False), folding stages behind a fold_field, or limiting visible selection values with statusbar_visible are XML attributes on the field, shown below. The header placement itself is also XML if you are not using the Stages feature.

Selection states in the header

<header>
    <field name="state" widget="statusbar"
           statusbar_visible="draft,posted"/>
</header>

Only draft and posted render inline; cancel appears only when a record is actually cancelled.

Read-only states (buttons move the record)

<field name="state" widget="statusbar"
       options="{'clickable': False}"/>

The strip shows position; workflow buttons with their validations do the moving. The pattern for anything accounting-adjacent.

Many2one stages with folding

<field name="stage_id" widget="statusbar"
       options="{'fold_field': 'fold'}"/>

Stages whose fold boolean is true collapse into the trailing dropdown, the same convention kanban columns use, so both views fold consistently from one flag.

The source registers two commands on every form-view statusbar, and they are the fastest way to move records that exists in Odoo.

Alt+X: move to the next stage. One keystroke advances the record, disabled only when the last stage is reached or the bar is read-only. For anyone processing a queue, screening applicants, confirming orders, this replaces a mouse trip per record.

Alt+Shift+X: move to any stage. Opens the command palette pre-filtered with every stage; type a few letters, hit enter. It respects the same rules as clicking, including the immediate save.

(On Mac these are Control+X flavored per Odoo's hotkey mapping; the command palette itself lists the exact keys.)

The other invisible machinery is responsive folding. The source documents a 4-scenario algorithm: everything inline when it fits; then stages before the current one collapse into a leading dropdown; then stages after it join the trailing one; and when nothing fits, the whole bar becomes a single dropdown, which is also the permanent behavior on small screens. Knowing this saves a bug report the first time a narrow window swallows your stages.

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 declares the same two options, the same statusbar_visible handling, and the same pair of commands. Internal component syntax moves to the new Owl props system, affecting JavaScript patches only. We re-verify once Odoo 20 ships.