progressbar

Numbers that represent completion deserve to look like completion. The progressbar widget renders an integer or float field as a horizontal filled bar with the number beside it: course completion on eLearning slides, recruitment skill levels, margin percentages.

Two display modes, decided by one option. Without max_value, the value is treated as a percentage of 100. With it, the widget shows current / max, both numbers formatted per their field types, with the bar filled proportionally. The value formatting is human-readable when idle, 1.2k style, and switches to the raw number the moment an input is focused, a detail read from the state handling in the source.

A separately registered kanban.progressbar variant exists for one reason: kanban records render readonly, and the variant drops the readonly veto so editable can still work on cards.

Progress bars earn their place on screens where a team manages many part-done things at once: campaign sends, hiring funnels, skill matrices, project completion. The bar converts a column of numbers into an instantly comparable shape, and the overflow color flags over-target rows without a filter.

The design decision that matters is editability. A read-only bar reports; an editable bar becomes a control, click, type, done, which is excellent for quick percentage updates on kanban cards and dangerous for computed values that should never be hand-set. Odoo 19 gives you that choice per view with editable. Note the direction of travel though: on the Odoo 20 development branch the option disappears and bars become editable wherever the field itself is editable, so decide by field readonly, not widget option, if you want a future-proof setup.

Studio exposes this widget on numeric fields. Odoo Studio is available on Enterprise plans.

1. Open the form or list and click Studio in the top menu.

2. Add or select an Integer or Decimal field.

3. In the Properties tab, set Widget to Progress Bar. The official Studio docs describe it for values that are usually computed, displayed against a percentage bar.

4. Set Readonly if the value is computed; the bar then purely reports.

Tip: Studio's docs note the field "cannot be edited manually" with this widget, which is true for what Studio configures; inline editing exists only through the editable option in view XML, below.

Studio sets the widget and stops there. Everything characteristic of this widget lives in options it does not expose: max_value for X / Y display, editable and edit_max_value for inline editing, overflow_class for over-target styling. All are one-line view XML changes, the bread-and-butter of Odoo view customization, and all except max_value disappear on the Odoo 20 development branch, so implement with that horizon in mind.

Percentage bar

<field name="completion" widget="progressbar"/>

No max configured, so the value reads as a percentage of 100.

X of Y against another field

<field name="sent_count"
       widget="progressbar"
       options="{'max_value': 'total_count'}"/>

Displays sent / total with the bar filled proportionally. The max field must be loaded in the view.

Undocumented: a constant maximum

<field name="score"
       widget="progressbar"
       options="{'max_value': 10}"/>

The prop accepts a number as well as a field name, so a fixed scale needs no dummy field. Verified from the prop typing and the isPercentage check in the source.

Inline-editable with overflow styling

<field name="progress"
       widget="progressbar"
       options="{'editable': True, 'overflow_class': 'bg-danger'}"/>

Users type the current value directly, and anything past the max turns the bar red instead of the default gray.

Details from the source that decide real-world behavior.

The readonly veto option. extractProps computes editability as !options.readonly && options.editable: an option named readonly, not the field state, not the attribute, can force a bar inert even with editable set. It appears in no documentation.

Why the kanban variant exists. The base component refuses editing when the record renders readonly, which kanban records always do. kanban.progressbar overrides exactly that check, trusting editable alone, and its inputs save immediately on commit, the mechanics behind editable progress on cards.

Integer parsing floors. Typed values run through float parsing and are floored for integer fields, so 7.9 stores as 7.

Overflow is a class swap, not a clamp. When current exceeds max, the fill class changes to the overflow class, gray by default, red if you say so. The bar does not cap the number.

The sale module ships a derivative. sales_team_progressbar extends the kanban variant to show either an invoicing target bar or a define-target link, a nice template for building your own derived bars.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The following reads the widget on the public development branch, which is unstable until feature freeze; we re-verify against the shipped release.

This is a redesign, not a tweak. Only max_value remains in supportedOptions. editable, edit_max_value, current_value, overflow_class and the undocumented readonly veto are all gone. Editability becomes simply "not readonly": clicking the bar focuses the value input. The max value is no longer editable inline at all, and the separate kanban variant file disappears with the base handling all views. Colors change model entirely: the bar reads standard view decorations, so decoration-danger expressions on the field now drive bar color, replacing overflow_class with the same mechanism lists already use.

Net effect: simpler, more consistent, and breaking for any view that used the deleted options. The XML keeps loading, the options just stop doing anything.