timesheet_uom

Most widgets decide how a field looks. This one decides which widget decides. On every timesheet duration, the unit_amount float on account analytic lines, Odoo places timesheet_uom, and at render time the component asks the timesheet_uom service which real widget to use.

The mapping, verified in the source, imports three candidates: FloatTimeField for companies encoding in hours (the familiar 08:30), FloatToggleField for companies encoding in days (click through 0 / 0.5 / 1), and FloatFactorField for units needing a conversion factor. The service picks one based on the company's configured encoding unit and hands it the field's props.

That indirection is why one settings change re-skins every timesheet screen consistently, and why this widget needs no per-view configuration anywhere.

Hours versus days is a business-model choice, not a display preference. Agencies and support teams bill precise hours; consulting and audit firms sell day rates. Odoo respects that with one setting, and this widget is the mechanism that makes the setting take effect everywhere at once: grids, task forms, invoicing previews.

The trap we see in implementations is fighting the dispatcher instead of setting the unit. Teams that want day-based entry sometimes hand-swap widgets on individual timesheet views; the result breaks the first time an updated module ships its own view. Set Encoding Unit to days and every view follows, including ones added by future modules.

The setting is also a data-entry contract: whatever users see, storage remains hours underneath, so utilization reports and sale-order billing stay consistent regardless of the display unit.

How core views use it

<field name="unit_amount" widget="timesheet_uom"/>

That is the entire integration: no options, no variants. What renders depends on the company at runtime.

Switching a company to day-based entry

Settings > Timesheets > Time Encoding > Encoding Unit = Days

Every timesheet duration switches from hh:mm inputs to the day toggle, with no view changes anywhere.

Using it on a custom model's hours field

<field name="hours_spent" widget="timesheet_uom"/>

Legal on any float, and your field inherits company-consistent duration rendering. Do this only when the value genuinely follows the timesheet encoding; otherwise use float_time directly and keep the meaning fixed.

The dispatch happens per render through the timesheet_uom service, and two consequences follow directly from that design, both verified in the component.

It is company-aware, not view-aware. The service resolves the encoding unit of the active company. In multi-company databases with different encoding units, the same shared view renders hh:mm for one company's users and the day toggle for another's, which is correct behavior and occasionally mistaken for a bug report.

The wrapped widget receives standard props untouched. The dispatcher forwards the field props to whichever component it picked. It adds nothing and filters nothing, so behavior questions are always answered on the delegated widget's page, float_time for hours encoding, the toggle for days. If hh:mm parsing behaves oddly on a timesheet, debug it as a float_time issue.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

The dispatcher itself is unchanged: same service, same three delegated widgets, still no options. What changes is underneath: float_time, which renders the hours case, gains renamed and new options and a typing preview in Odoo 20 (detailed on the float_time page). Hour-encoding companies will therefore see the new time-entry behavior on timesheets without any change to this widget. We re-verify once Odoo 20 ships.