rotting

Odoo 19 introduced a pipeline hygiene feature the source calls rotting: a record that has not left its stage within a stage-defined number of days is flagged, searchable, and visually marked. The rotting widget is the kanban part of that marking. It renders a small rounded pill with the number of days the record has been stuck, such as 12d, and a tooltip explaining it, with wording that adapts to the model: leads get "This lead has been stuck in this stage for 12 days.", applicants and tasks get their own phrasing, and any other model gets a generic sentence.

The widget itself is deliberately dumb. It has no options, computes nothing, and renders nothing at all unless the record's is_rotting boolean is true. All the logic lives server side in mail.tracking.duration.mixin, which computes is_rotting and rotting_days from the record's last stage change and the stage's rotting_threshold_days value. A threshold of 0 on the stage disables rotting entirely, which is the default.

In core, the field element the widget sits on is rotting_days itself, placed inside the kanban card next to the salesperson avatar. CRM leads, recruitment applicants and project tasks are the three models wired up in Odoo 19.

Every pipeline accumulates dead weight: the quote nobody chased, the applicant nobody called back, the task that quietly stalled. Before Odoo 19 you found those by sorting on a date column or building a filter, which means you found them when you went looking. Rotting inverts that: the pipeline itself tells you, on every kanban card, that something has been sitting too long.

The decision that matters is the threshold per stage, and it belongs to whoever owns the process. A five day threshold on a "Proposal sent" stage encodes the rule that no proposal goes a week without a follow up. Stages where waiting is normal, such as "Won" or a long legal review, should keep the threshold at 0 so the team does not learn to ignore red badges. In our implementations the fastest way to kill this feature is to set aggressive thresholds on every stage at once; within a month the whole board is red and nobody sees it anymore.

Because is_rotting is searchable, the same feature powers a stock Rotting filter in the CRM search panel, so a sales manager can open the pipeline, apply one filter, and run the Monday review from exactly the records that need rescuing.

The core pattern, from the CRM pipeline kanban

<field name="is_rotting" invisible="1"/>
<field name="rotting_days" class="d-flex" widget="rotting"/>

The widget goes on rotting_days; is_rotting rides along invisibly as the display gate.

Enabling rotting on a custom model

The model needs the mixin and a tracked stage field, and the stage model needs the threshold:

class HelpdeskTicket(models.Model):
    _name = "my.ticket"
    _inherit = ["mail.tracking.duration.mixin"]
    _track_duration_field = "stage_id"

class TicketStage(models.Model):
    _name = "my.ticket.stage"

    rotting_threshold_days = fields.Integer("Days to rot", default=0)

The mixin also expects a date_last_stage_update datetime on the model; with those pieces in place, is_rotting and rotting_days exist and the three rotting widgets work.

Filtering rotting records

<filter string="Rotting" name="filter_rotting" domain="[('is_rotting', '=', True)]"/>

The mixin's docstring maps the three widgets to their views in one line: "'rotting' for kanbans, 'rotting_statusbar_duration' for forms, 'badge_rotting' for lists." That sentence is the official architecture of the feature, and it explains a behavior that otherwise looks like a bug: rotting is registered in the fields registry as kanban.rotting only. There is no unprefixed registration, so putting widget="rotting" in a list or form view resolves nothing and falls back to the field's default widget. Use badge_rotting and rotting_statusbar_duration there instead.

Which stages can rot is a per-stage decision, and the threshold help text carries a subtlety worth knowing: changing rotting_threshold_days does not retroactively recompute records whose stage was last updated before the change. A stage that just got a threshold will start flagging records as they age under the new rule, not instantly repaint history.

Models can also narrow when rotting applies by overriding _get_rotting_domain(). CRM does exactly that: leads only rot while their won_status is pending, so won and lost opportunities never show the badge no matter how long they sit.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch, which is unstable and can still move before release; we re-verify this page against the shipped version.

The widget is renamed. On master, the component is RottingDaysField and the registration changes from kanban.rotting to rotting_days, with no view prefix, so it can be used in any view type. Custom kanban archs using widget="rotting" will need to switch to widget="rotting_days" after the upgrade.

The old name is reassigned, not retired. The list widget currently registered as list.badge_rotting becomes plain rotting on master. The name you use today for the kanban pill will, in Odoo 20, resolve to the list-style badge component instead. This is the sharpest rename gotcha we have seen in the 20 cycle so far, and it is exactly the kind of change our Odoo migration service greps for.

Internals move to the new props system (useProps, record.resModel instead of record.model.config.resModel), which only affects code that patches the component.