many2one_avatar_employee

Anywhere an HR flow points at a person, an expense's employee, a leave request's owner, an appraisal's subject, this widget draws the photo next to the name. It composes the standard many2one with the HR avatar component, so searching, the dropdown and the record link all behave like the field users already know.

What makes it more than styling is a permission check in setup, verified in the source: the widget asks whether the current user belongs to the HR officer group, and if not, it reads from hr.employee.public, the sanitized mirror of the employee table, instead of hr.employee. Same field, same look, but a warehouse operator picking a colleague never touches records carrying salary-adjacent data.

Two hardcoded choices round it out: quick-create is off (the m2o props force canQuickCreate: false), and the link to the employee record opens only from form views unless explicitly enabled, both sensible defaults for HR data.

Employee references are everywhere once HR apps are live, and two risks travel with them: private data leaking through innocent dropdowns, and junk employee records created by typo. This widget closes both by construction, which is why the honest business advice is simply: use it on every employee field, and be suspicious of views that render employees with a plain many2one.

The public-model switch also explains a support question that otherwise looks like a bug: an operations user and an HR officer can see slightly different employee lists in the same dropdown, because record rules on hr.employee.public and hr.employee differ. That is the privacy design working, and knowing it saves an escalation.

Faces also carry real workflow value in approval queues: an expense or leave list with photos is scanned by person, not read by name, and approvers triage noticeably faster.

Studio applies this widget in seconds.

1. Open the view in Studio and select the employee many2one field.

2. In Properties, open the Widget dropdown and pick the avatar employee entry.

The behavioral options stay in XML: forcing the model with relation, enabling the list-view link with no_open: False, or locking the dropdown down further with no_create. Each is a one-line option shown below.

Standard employee field

<field name="employee_id" widget="many2one_avatar_employee"/>

Clickable in list views

<field name="employee_id"
       widget="many2one_avatar_employee"
       options="{'no_open': False}"/>

Without the option the avatar is a plain display in lists, the same form-only default the user avatar widget has.

Pinning the model

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

Forces the public model for every user, occasionally right for screens that should never show more than the directory view, whatever the viewer's rights.

The one-line relation getter is the widget's whole security story, and it deserves the spotlight: this.props.relation ?? (this.isHrUser ? "hr.employee" : "hr.employee.public").

hr.employee.public is Odoo's directory-safe projection of the employee table: name, photo, job, department, contact points, and none of the private HR fields. By steering non-HR users there, the widget lets you put employee pickers on any screen, expenses, timesheets, custom models, without extending HR access rights just so a dropdown works. The check is the hr.group_hr_user group, resolved once at component start.

Two contrasts with its sibling many2one_avatar_user keep teams from mixing them up. That widget points at users (login accounts), carries Discuss presence and the Assign-to-me command; this one points at employees (HR records), has no presence dot and no command, and instead carries the privacy switch. Assignment workflows want users; HR flows want employees; a person can be both, and the two fields still should not be conflated.

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.

Nothing changes for this widget. The development version keeps the same relation switch, the disabled quick-create, the form-only link default and both extra registrations. Internal syntax moves to the new Owl props system, affecting JavaScript patches only. We re-verify once Odoo 20 ships.