timesheet_uom_no_toggle

Odoo timesheets store hours, but companies encode effort in different units, hours or days, set per company as the timesheet encoding unit. The timesheet_uom family exists to honor that setting automatically: a widget asks the timesheet_uom service which renderer fits the company, and the service answers float_time for hour encoding, float_toggle for day encoding.

This widget is that dispatcher with one opinion added: it never serves the toggle. Its single override checks whether the service resolved to float_toggle and swaps in float_factor instead, the same factored number rendering without the clickable button. The source even removes the toggle component from the inherited component registry, one deleted key, so the class carries only what it can render. Everything else, the service lookup, the props pass through, the registration pattern, is inherited from timesheet_uom unchanged.

The toggle in float_toggle is an input device: clicking cycles the value through preset steps, handy for an employee logging half days. That stops being handy the moment the number is informational, a total, a shared task's logged effort, a figure shown to a customer, because a stray click edits data. The no toggle variant is Odoo's answer, and core applies it across the task sharing views, where outside collaborators see effort figures that must stay read only in spirit even when the field is technically editable.

The takeaway for implementations is a simple pairing rule: entry screens for day encoding companies get timesheet_uom and its toggle, display screens get timesheet_uom_no_toggle. Teams that standardize on that pairing stop seeing the "someone changed my logged days by accident" tickets, and the reports built on timesheet data stay trustworthy without extra locking.

Effort total on a shared task, no toggle

<field name="effective_hours" widget="timesheet_uom_no_toggle"/>

Entry line where the toggle is welcome, for contrast

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

The model side is always plain hours

effective_hours = fields.Float("Hours Spent", compute="_compute_effective_hours")

Whatever the widget displays, the stored value is hours; day encoding is a display factor applied by the renderer, not a stored conversion.

The full dispatch chain, as read in the source: the component asks the timesheet_uom service for the timesheet component matching the current company. The service resolves the company's encoding unit to a widget name, float_time for hours, float_toggle for days, and hands back the matching component and props. This widget's single getter intercepts exactly one case: a float_toggle answer is remapped to float_factor, the renderer that multiplies the stored hours by the unit factor and prints the number plain.

Two implications are worth pinning down. First, in hour encoding companies the two timesheet widgets are indistinguishable, both serve float_time, so a missing toggle only ever signals anything in day encoding companies. Second, because resolution happens per company at render time, a multi company database can legitimately show the same field as clock format hours for one company's users and factored days for another's, which is correct behavior, not a bug report.

The class also deletes FloatToggleField from its inherited static components, so the unused renderer is not even carried as dead weight. It is a tidy example of Odoo's composition pattern: fork by one getter, not by copy paste.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and as always for unreleased versions, the statements here are read from the public development branch and re-verified once the release ships.

This file is byte identical on master. Both timesheet_uom_no_toggle.js and its parent timesheet_uom.js show no diff at all against 19.0 at the time of writing, not even formatting churn. The dispatch service, the substitution and the registration carry into 20 as they are.

The dependency direction to watch is the underlying renderers: this widget's output is whatever float_time and float_factor do, so changes to those fields in 20 would surface here without this file changing. Our pages for the underlying widgets track that directly.