mrp_timer

A work order's duration is a stored number, updated when the operator clocks off. While they are still working it is out of date by definition, and showing a stale figure on a shop floor screen is worse than showing nothing.

This widget shows a live one. When the record says the current user is working on it, the widget asks the server how long that has actually been, then counts up from there, so the number on screen matches the clock rather than the last save.

When nobody is working, it simply formats the stored value. The same widget therefore serves a running work order and a finished one without the view needing to distinguish them.

Shop floor time is the input to costing, capacity planning and, in many businesses, payroll. A timer that resets or drifts on a page reload undermines all three, and it is the first thing an operator stops trusting.

Asking the server for the elapsed time rather than counting from when the page loaded is what makes it reliable. An operator who starts a job, walks away and comes back to a refreshed browser sees the real elapsed time, not a timer that restarted.

The practical requirement is that the record carries the flag saying whether the current user is working. Without it the widget has nothing to key the live behavior on, and shows a static number.

The usual usage

<field name="duration" widget="mrp_timer"/>

Ticks while the current user is working on the record, and formats the stored value otherwise.

The companion field it needs

<field name="is_user_working" invisible="1"/>

Read by literal name. Without it the timer never runs.

A plain duration

<field name="duration" widget="float_time"/>

Hours and minutes with no live behavior, correct for a completed order.

The important decision is where the running value comes from. Rather than counting from page load, the widget calls a server method for the record's real duration when it detects that work is in progress, then advances that number locally. That is what makes the display survive a refresh.

The local ticking is a repeating timer stored on the instance, and it is cleared when the component is destroyed. Forgetting that cleanup is the classic way a timer widget leaks, so its presence is worth noting when writing something similar.

Re-syncing is handled in the formatting getter rather than by an observer. If the record is dirty and the field's value differs from what the widget is showing, it adopts the record's value. That covers the case where something else on the form changes the duration while the timer is running.

The formatter registration alongside the widget means the minutes format is available by name to other Manufacturing code, which is why work order durations look consistent across screens that do not all use this widget.

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.

Behavior is unchanged. The server lookup for a running timer, the local ticking, the cleanup and the re-sync all behave the same. The differences follow the wider component migration and affect patches rather than views.