many2many_avatar_employee

Anywhere Odoo needs "pick several employees", the multi-employee allocation wizard in Time Off being the canonical case, this widget draws each selected employee as a pill with their photo and name, plus an autocomplete to add more. Visually it is the same experience as the assignee pickers on tasks, because it extends exactly that widget, many2many_avatar_user, which in turn extends the generic avatar-tags field.

What the employee variant adds is model awareness. Odoo splits employee data between hr.employee, the full record HR can see, and hr.employee.public, the trimmed version every user may read. The widget checks hr.group_hr_user membership when it loads and aims its searches, avatars, and cards at whichever model the current user is entitled to. The same field therefore works for an HR officer and a regular employee without access errors, showing each exactly what they are allowed.

It also decides one thing firmly: employees are not created from a picker. The descriptor hardcodes quick create off, so the dropdown only ever offers existing employees.

The model switch is invisible when it works, which is the point, but it explains two things administrators run into. First, avatars and names can differ subtly by user: non-HR users see the public employee record, so anything HR maintains only on the full record does not surface for them. Second, record counts in the picker can differ between users when record rules scope the public model, say per company. Neither is a bug; both are the access design doing its job in the UI.

The no-creation rule is a data-governance decision embedded in a widget. Employee records carry contracts, payroll links, and access implications, so "quickly add Jane" from a wizard is exactly how HR databases grow duplicate half-employees. Odoo's choice to disable it here is one to preserve in customizations: if a flow seems to need employee creation mid-picker, the flow is usually wrong, not the widget.

For custom models that relate to employees, the widget is reusable as-is, and the relation option covers the edge case of always targeting one specific model, for example pinning to the public model so a shared screen never exposes HR-only data.

As core uses it in the allocation wizard

<field name="employee_ids" widget="many2many_avatar_employee"/>

Pinned to the public model

<field name="employee_ids" widget="many2many_avatar_employee"
       options="{'relation': 'hr.employee.public'}"/>

The HR-group switch is bypassed; every user, including HR, works against the stated model.

Blocking the popup-create route too

<field name="employee_ids" widget="many2many_avatar_employee"
       options="{'no_create': True}"/>

Quick create is already off; this removes the Create and Edit dialog path as well, making the picker strictly select-only.

The version history of this small file is a map of where the widget's behavior comes from.

Odoo 16 hardcoded the safe answer. The 16 implementation pinned relation to hr.employee.public for everyone, HR users included, though it already accepted a relation override from options. The group-aware switch arrived in 17 with the shared EmployeeFieldRelationMixin, which is also what the many2one employee variants use.

Odoo 19 made the pills clickable. The displayAvatarCard override, showing the employee card popover on desktop whenever the resolved relation is one of the two employee models, is new in 19, as are the dedicated list. variant and the activity. registration. On 17 and 18 the variants existed without the card override and activity views fell back to the kanban variant only.

The mixin is the extension point. If you build an avatar field for another split-access model, the pattern to copy is exactly this file: wrap the user-avatar classes with a mixin that resolves the relation from a group check and passes it into the avatar card props. The widget layer stays five lines per variant.

One inherited behavior worth restating from the avatar family: in kanban views the visible avatars are capped (with a counter pill for the rest), and the kanban popover editing flow saves the record on every change, both inherited from the avatar-user implementation.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. These notes come from the public development branch, which is unstable until feature freeze; we re-verify against the shipped release.

Three visible changes. The kanban variant is renamed: kanban.many2many_avatar_employee becomes card.many2many_avatar_employee, with the activity registration now pointing at the card variant, part of the framework-wide kanban-to-card rename; any patch targeting the old registry key needs updating. The card variant gains a "Search employee..." placeholder. And the mixin signature changes to take the props set as a second argument as part of the props-validation migration, which affects custom code extending EmployeeFieldRelationMixin directly.