mrp_workorder_popover

A work order that cannot start has a reason: a component is missing, an earlier operation is unfinished, the schedule has drifted. Those reasons are computed on the server and are useless unless they reach the person looking at the list.

This widget puts them behind an icon on the row. Clicking it opens a popover with the messages, each carrying its own color so a warning reads differently from an error, and the whole thing is driven by a JSON payload rather than by view configuration.

What it adds beyond the inventory popover it extends is an action. When the payload says the order can be replanned, the popover offers a button that does exactly that, without leaving the list.

Replanning from the row is the point. A planner working through a list of blocked orders otherwise has to open each one, find the action and come back, and the friction is enough that lists go unreviewed.

The full reload after replanning is worth explaining rather than optimizing away: moving one work order moves others, so anything short of reloading would show a list that disagrees with the schedule. Slower and correct beats instant and wrong on a planning screen.

The other thing to know is that the icon can be suppressed entirely by the payload, which is how orders with nothing to report stay visually quiet.

The usual usage

<field name="json_popover"
       widget="mrp_workorder_popover"/>

No options. The icon, its color and the messages all come from the payload.

The documented payload

{
  "replan": true,
  "color": "text-warning",
  "infos": [
    {"msg": "Waiting for components", "color": "text-danger"}
  ]
}

The replan flag decides whether the button appears; each message carries its own color.

Hiding the icon

{ "color": "d-none" }

The comment names this as the way to suppress the marker entirely.

Two small classes. The popover subclass adds the replan handler, and the field subclass points the base widget at that popover.

The replan handler calls a named method on the work order model with the record's identifier and then reloads the model. The reload is the significant half: replanning a work order shifts the schedule of others, so refreshing only the clicked row would leave the rest of the list stale.

The popover subclass's initialization does not chain to the parent's. For a popover component that is defensible, since the base sets up the popover host rather than the content, but it is the kind of thing to check before extending this widget further.

The payload contract is documented at the top of the file, which is unusual and useful: the replan flag, the icon color with its hidden convention, and a list of message objects each carrying its own color. Everything the user sees comes from there.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify this page after the release.

The widget is split in two. On the development branch there is no registration under this name; its responsibilities appear instead as a bill of materials popover and a separate planning status widget, each with its own file.

Because an unknown widget name falls back to the field's type, a view still naming this one would render the raw payload string. Custom manufacturing views should be checked before that upgrade, and any server code producing the payload re-examined against the new shapes.