badge_rotting

Odoo 19's rotting feature flags records that have overstayed their pipeline stage, and each view type gets its own widget for the flag. badge_rotting is the list-view one. Applied to the stage column, it renders the normal many2one value and, when the record's is_rotting boolean is true, appends a small rounded pill with the day count, formatted as 15d.

Under the hood it is Many2OneFieldRotting, built with buildM2OFieldDescription on top of the standard many2one field. That construction matters: the widget inherits the entire many2one option set, and core immediately uses it, shipping the CRM lead list with options="{'no_open': True}" so clicking the stage does not navigate away from the list.

One deliberate omission is documented in the source itself: because the pill is appended to another field's value, the component sets no tooltip of its own, "to prevent title overlap" with the many2one's title attribute. The kanban sibling shows the explanatory sentence on hover; the list badge stays quiet.

Pipeline reviews happen in list views more often than managers admit: sort by salesperson, scan, and ask questions. badge_rotting puts the neglect signal directly in the column people already scan. A stage cell that reads Proposition 15d answers the first review question, "how long has this been sitting there", without a click, a filter, or a computed date column.

The practical wiring is one decision per stage: how many days is too many. That number, rotting_threshold_days, lives on the stage record and doubles as the on-off switch, with 0 meaning never rot. Thresholds should encode your follow-up rules, not a blanket ambition; a stage where a week of waiting is normal gets a higher number or stays off, otherwise the badge becomes wallpaper.

Because the same computation also powers the stock Rotting search filter, the list view combination is strong: filter to rotting records, keep the badge column visible for the day counts, and you have a ready-made recovery worklist for the Monday pipeline meeting.

The core pattern, from the CRM lead list

<field name="stage_id" optional="show" widget="badge_rotting" options="{'no_open': True}"/>
<!-- further down the same list -->
<field name="is_rotting" column_invisible="True"/>
<field name="rotting_days" column_invisible="True"/>

Locking the column down further

<field name="stage_id" widget="badge_rotting"
       options="{'no_open': True, 'no_create': True}"/>

Both options come straight from the inherited many2one behavior: no navigation on click, no creating stages from the editable list cell.

Building the widget on the many2one descriptor rather than as a decoration has consequences worth knowing.

It is fully editable. In an editable list, the cell behaves exactly like a stage many2one: autocomplete, quick create, Search More, all subject to the usual options. The pill is cosmetic; editing writes to the stage field normally, and moving the record to a new stage resets the rot clock server side through date_last_stage_update.

The registration is list-prefixed. list.badge_rotting means the fields registry resolves it only inside list views. In a form or kanban arch, widget="badge_rotting" silently falls back to the default many2one. The mixin's docstring assigns the other views their own widgets: rotting for kanbans, rotting_statusbar_duration for forms.

The day count is a separate field from the one you place it on. You put the widget on stage_id, but the number in the pill comes from rotting_days, computed by mail.tracking.duration.mixin against the stage's rotting_threshold_days. CRM narrows it further: only leads whose won_status is pending can rot, so won and lost rows never badge.

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

The widget is renamed to rotting, dropping the list prefix, so it becomes usable in any view type. The rename collides head-on with today's naming: in Odoo 19, rotting is the kanban day-pill widget; on master that kanban widget becomes rotting_days and the name rotting now means this list badge component. Any custom arch using either name needs a review at upgrade time, and a find-and-replace done in the wrong order will swap the two behaviors. This is precisely the sort of silent semantic change our migration service audits for.

Internals follow the new props system (useProps, Record type imports), relevant only to code patching the component.