task_with_hours

Timesheet entry lives or dies on how fast people can find the right task. task_with_hours is the hr_timesheet module's answer: a many2one for task_id whose dropdown labels every candidate task with how much of its allocated time is left, so the person logging hours can see at a glance which bucket still has room.

The mechanism is a clean client-server split, read directly from the source. The widget injects one context key, hr_timesheet_display_remaining_hours, into the dropdown's search. Server side, project.task reacts to that key in _compute_display_name by appending a suffix after a non-breaking space: (08:00 remaining) in hour-and-minute form, a minus sign in front when the task is overdrawn, or (1.5 days remaining) when the company's timesheet encoding unit is days. The suffix only exists for tasks where timesheets are allowed and allocated hours are set above zero.

The same widget then hides its own suffix once a value is picked: the display name is cut at the first non-breaking space, so the selected chip reads just the task name. The dropdown informs, the field stays clean.

The remaining-hours suffix turns timesheet entry into soft budget control. When a consultant sees (02:15 remaining) next to a task, the message lands before any report is run: this bucket is nearly spent, either wrap up or flag it. Teams that bill fixed-price projects get their early-warning system inside the field where hours are logged, which beats a variance report read two weeks too late.

The creation gate is equally deliberate. Letting people invent tasks from a timesheet line is how project structures rot, so the widget only allows creating a task when the line already carries a project, and the new task lands in that project. No project selected, no create option at all. That single rule keeps orphan tasks out of the database while still letting a project lead add a legitimate missing task mid-entry.

For the suffix to mean anything, allocated hours must be filled on tasks. Projects that skip allocated_hours get plain dropdowns, no warning, no budget signal, which is a data discipline point to bake into your project templates rather than a widget setting.

The core pattern, from timesheet line views

<field name="task_id" widget="task_with_hours"
       context="{'default_project_id': project_id}"/>

The context line is doing double duty: it presets the project on any task created from the dropdown, and its presence is what unlocks creation at all.

Read-only style task reference with hours in the dropdown

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

The model side that feeds the suffix

allocated_hours = fields.Float("Allocated Time")
remaining_hours = fields.Float(compute="_compute_remaining_hours")

Both are standard project.task fields; fill allocated time and the dropdown starts talking.

Two source details explain most surprises with this widget.

The suffix lives in the display name, not in the widget. The client never computes hours; it just passes the context key and trims what comes back at the first non-breaking space (\u00A0). That character is the entire contract between server and client. A custom _compute_display_name override that drops the NBSP, or replaces it with a regular space, silently breaks the trimming and the selected chip starts showing the suffix too.

Negative remaining time renders with a minus. The server formats overdrawn tasks as (-03:30 remaining), so the dropdown flags budget overruns, not just budgets running low. With day encoding it converts through the company UoM instead.

The version history is a study in Odoo's widget migrations. Odoo 16 shipped the behavior twice, once as an OWL component and once as a legacy widget for the old grid view. 17 consolidated on the component, subclassing Many2OneField, and 18 kept that file byte for byte. 19 rewrote it compositionally, wrapping the new Many2One building block and computing props instead of overriding getters, the same rewrite wave that hit every m2o-based widget. Behavior across all four: identical, which is why the version table below stays green.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and the notes below read the public development branch, which can still change before release.

No behavior changes are visible on master. The diff is limited to the framework props migration: useProps with the shared many2OneFieldProps instead of static props. The context key, the NBSP trim, and the project-gated creation are all untouched, and the server-side display name logic is unchanged.

Watch the base widget instead: whatever the many2one gains or loses in 20 flows straight through this descriptor, so read that page's Odoo 20 section alongside this one when planning an upgrade. We re-verify both after release.