many2one_work_entry_type

many2one_work_entry_type dresses the standard many2one with the visual identity of work entry types. Each type in payroll carries a short code (display_code) and a calendar color, and this widget shows both as a compact chip, a rounded 5 character badge tinted with the o_calendar_color_<n> class, in two places: before the field's input and inside every row of the autocomplete dropdown.

Two source mechanisms make that work. The widget declares display_code and color as field dependencies, and its m2oProps getter extends the relational specification with both fields, so the dropdown's search results arrive with code and color attached instead of just names. A custom Many2One subclass then pipes the full record, not just id and name, into the update path.

One hardcoded assumption: the render hook reads record.data.work_entry_type_id literally to decide which data feeds the chip. On a field with any other name the chip falls back to the record's own data and shows nothing useful.

Payroll admins live in dense screens where Attendance, Overtime and Sick Time differ by one word. The code chip plus color gives each type a stable visual identity, the same one used on the work entry calendar, so scanning hundreds of entries against the calendar becomes pattern matching instead of reading.

If you run custom payroll flows, the widget rewards data discipline: give every work entry type a short, distinct display_code and a color, and the whole chain, calendar, list, form dropdown, stays legible. Types without a code render an empty chip, which looks broken to users.

The plain usage from hr_work_entry_views.xml:

<field name="work_entry_type_id" widget="many2one_work_entry_type"/>

The locked down variant on validated entries, combining inherited many2one options with readonly logic:

<field name="work_entry_type_id" readonly="state == 'validated'"
       options="{'no_create': True, 'no_open': True}"
       widget="many2one_work_entry_type"/>

The interesting engineering is in how the chip stays correct:

The specification injection. A normal many2one autocomplete fetches id and display name. This widget's m2oProps getter adds specification: { display_code: 1, color: 1 }, so every dropdown row carries the chip data with no extra round trips. The custom WorkEntryTypeMany2One subclass overrides the autocomplete's update callback to hand the full record through, because the default path would strip the extra fields.

The render time switch. On each render the field checks whether record.data.work_entry_type_id carries a color; if so the chip feeds from the linked type, otherwise from the record's own data. This is what ties the widget to that exact field name.

A typing quirk. The dependency declaration types color as char although work entry type colors are integer indexes; the value is only ever interpolated into a CSS class name, so the mismatch is harmless in practice.

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 chip subcomponent is deleted. Master removes the WorkEntryType component and its extractData helper from this file; the field becomes a lean composition over the shared many2OneFieldProps, keeping the same registration, dependencies and specification injection.

Missing data is re fetched. The autocomplete update becomes async: when a chosen record lacks display_name, display_code or color, the widget performs an orm.read for exactly those three fields before updating, closing a gap where selections made through nonstandard paths lost their chip.

We will re verify this page against the released branch after the launch.