statusbar_duration

The widget renders the familiar stage buttons across the top of a form, then asks the record for one extra piece of data: duration_tracking, a JSON object mapping stage ids to seconds spent. Every stage with a positive duration gets a muted suffix such as 5 days, with the precise long form in the tooltip.

The display name Odoo gives it is Status with time. It is a thin subclass of statusbar: one overridden method decorates the stage items, and templates inject the duration span on both the desktop buttons and the mobile dropdown. Everything else, clicking to change stage, folded stages, responsive folding, comes from the parent.

Two descriptor changes matter. supportedTypes is narrowed to many2one only, so unlike the base statusbar you cannot put it on a selection field. And it declares fieldDependencies on duration_tracking, which is why the durations appear without you adding anything to the view.

Time in stage is the metric behind most pipeline questions: where do tasks stall, how long does qualification really take, which handoff is the bottleneck. This widget surfaces that number exactly where people already look, on the stage bar itself, without a report or a BI tool.

Because the durations are computed from the chatter's tracking history, they are audit-grade: the clock starts and stops on actual recorded stage changes, not on manual timestamps someone forgot to update. A task that bounced back to Doing twice shows the accumulated total.

The practical payoff is in reviews. A project lead scanning a task sees 12 days next to Waiting and asks the right question immediately. Teams we work with often pair it with stage discipline rules, since the numbers are only as honest as the stage changes behind them.

How core applies it (project sharing task form)

<field name="stage_id" widget="statusbar_duration"
       options="{'clickable': '1', 'fold_field': 'fold'}"
       invisible="not project_id and not stage_id"/>

Enabling it on a custom model

The widget is the easy half. The model must opt into the mixin and point it at a tracked many2one:

# the field named in _track_duration_field must have tracking=True
class RepairOrder(models.Model):
    _name = "x_repair.order"
    _inherit = ["mail.tracking.duration.mixin"]
    _track_duration_field = "stage_id"

    stage_id = fields.Many2one("x_repair.stage", tracking=True)

Then in the form view:

<field name="stage_id" widget="statusbar_duration" options="{'clickable': '1'}"/>

If _track_duration_field is missing, names a non many2one, or the field is not tracked, the server compute raises a ValueError instead of failing silently; the error message spells out both requirements.

Understanding where the numbers come from explains every quirk of this widget.

Computed from the chatter, not stored. In Odoo 19, duration_tracking is a non-stored computed JSON. On every read the server walks mail.tracking.value rows, the same records that power the stage change lines in the chatter, and adds up the intervals per stage id. Delete the chatter messages and the durations change; that is by design, the tracking history is the single source of truth.

Keys are stage ids as strings. The JSON looks like {"1": 1230, "2": 2220}, seconds per many2one id. This is why supportedTypes is many2one only: a selection value has no id to key on.

The current stage shows accumulated past time only. In 19 the value for the stage the record is sitting in now covers completed intervals, frozen at the last stage change. The Odoo 20 branch is precisely about fixing this: the JSON gains an s key naming the active stage and a d key with its start datetime, and the widget adds the elapsed time client-side with luxon so the current stage ticks live.

Subclasses carry the feature elsewhere. Project's internal task form uses rotting_statusbar_duration, which inherits everything here and adds the stale-record pill. If you are reading durations on a task form, you are usually looking at the subclass.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and the development branch is not final until release. The changes visible there are substantial for this widget:

The JSON is stored and switches units. duration_tracking becomes a stored field with @api.depends on the tracked field, and values move from seconds to minutes. The widget compensates by multiplying by 60 before formatting.

Live ticking. The JSON gains two reserved keys: s, the active stage id, and d, the UTC datetime the stage started. The widget computes elapsed time client-side and adds it to the active stage, so the current stage's duration updates live instead of freezing at the last change.

A new guard. The rendering path requires the d key; a JSON without it, such as one produced by 19-era custom code, renders no durations at all. Custom modules that write duration_tracking directly will need to adopt the new shape. We re-verify against the shipped release.