rotting_statusbar_duration

Three widgets are stacked inside this one name. At the base sits the standard statusbar, the arrow-shaped stage bar at the top of pipeline forms. On top of it, the mail module's statusbar_duration adds time-in-stage labels, read from duration_tracking, a JSON field that mail.tracking.duration.mixin maintains with the seconds spent in each stage. rotting_statusbar_duration is the third layer, added in Odoo 19: it swaps in a template that highlights the rotting state and sets a hover tooltip that spells the problem out, with model-aware wording such as "This lead has been stuck in this stage for 12 days."

Because each layer spreads the descriptor of the one below, the whole statusbar feature set survives intact: stages stay clickable, folded stages collapse behind the ellipsis, statusbar_visible trims which stages show, and the form-only keyboard commands keep working. The only narrowing is the field type: the duration layers require a many2one stage field, while plain statusbar also accepts selection fields.

A pipeline form answers two questions badly by default: how long has this record been with us, and where did that time go. This widget answers both in the header. Each past stage carries the time it consumed, and the current stage carries the time so far plus, past the stage's rot threshold, the stuck warning. For a sales manager doing deal reviews, the stage bar alone now tells the story that used to need the chatter archaeology.

The durations are also quietly one of the best process-mining tools in Odoo. If "Proposal" routinely eats three weeks while "Qualified" takes a day, the bar says so on every record, and patterns become visible to the people working the records rather than only to whoever builds the quarterly report. We have seen stage definitions get renegotiated within weeks of teams simply seeing these numbers.

The rot warning rides on the same per-stage threshold as the rest of the rotting family: rotting_threshold_days on the stage, 0 meaning off. Configure it where waiting is a process failure, leave it off where waiting is the process.

The core pattern, from the CRM opportunity form

<field name="stage_id" widget="rotting_statusbar_duration"
       options="{'clickable': '1', 'fold_field': 'fold'}"/>
<!-- elsewhere in the same form -->
<field name="is_rotting" invisible="1"/>
<field name="rotting_days" invisible="1"/>

Read-only bar with trimmed stages

<field name="stage_id" widget="rotting_statusbar_duration"
       options="{'clickable': False}"
       statusbar_visible="new,qualified,won"/>

Users see durations and the rot warning but change stages through buttons or the kanban instead of the bar.

Where the durations really come from. duration_tracking is stored as a JSON map of stage id to seconds, recomputed from the record's tracking messages by mail.tracking.duration.mixin. The widget formats each entry twice, short for the label and long for its tooltip. A stage with no recorded time shows no duration label at all. If the bar shows no durations anywhere, the model is missing the mixin or the _track_duration_field does not point at the field you put the widget on.

What the rotting layer actually changes. Reading the source, the subclass does exactly two things: a template override that exposes the rotting state, and a title tooltip built from rotting_days with per-model wording for crm.lead, hr.applicant and project.task plus a generic fallback for custom models. Everything else, including which stages fold and the click-to-change behavior, is untouched inheritance.

Why there are two statusbar duration widgets. The mail module registers statusbar_duration for models that track durations but have no rotting configured, and rotting_statusbar_duration for the three pipelines that rot. Both accept the same options; the rotting variant is the one to use on any custom model where you enable the rotting mixin, otherwise the stuck state has no form-view representation.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. Findings below are from the public development branch, which is unstable until release; we re-verify after launch.

The widget file itself is unchanged on master, byte for byte, and keeps its name while its two siblings are renamed. What changes is inherited: the statusbar_duration base gains live tracking of the current stage. The duration_tracking payload grows an active-stage marker and start date, and the widget adds the elapsed time since that start client side, so the current stage's counter is up to date the moment the form opens instead of frozen at the last write.

The units contract changes with it. On master the stored tracking values are treated as minutes and multiplied back to seconds for formatting, where 19 reads them as seconds directly. Custom code that writes or reads duration_tracking raw will need attention during an Odoo 20 migration.