many2one_avatar_user

Anywhere Odoo shows a responsible person as a small round photo, a task's assignee, a lead's salesperson, an approval's manager, this widget is doing it. It takes a many2one to res.users and renders the user's avatar beside the name instead of a bare text link.

The avatar is not decoration. Hovering it surfaces the user's online status through Discuss presence, and opens a card with a direct message shortcut. The autocomplete dropdown is replaced too: while you search for a user you see faces next to names, which is materially faster in companies where half the sales team is named Patel.

The component builds on the standard many2one, so everything you know about that widget, searching, quick create, the internal link, applies here with the same options.

Ownership is the difference between a record and a commitment. The moment a task, lead or ticket shows a face, someone is answerable for it, and everyone can see who without opening anything. Teams consistently report that boards with avatar columns get triaged faster than boards with name columns; the face is scanned, the text is read.

The Assign to me command this widget registers is the sleeper feature. A support agent working through a queue does not open each ticket's assignee dropdown; they hit Ctrl+K, type "assign", enter, next. Multiplied across a team and a day, this is minutes saved per person, and adoption of it is a good proxy for how comfortable your team actually is in Odoo.

For managers, presence on the avatar answers "is she online right now" without a Slack round trip, which matters for the handoffs that keep response-time SLAs honest.

Studio does not create this widget from the field palette, but applying it to an existing user field takes seconds.

1. Open the form or list in Studio.

2. Select the user field, for example Salesperson or Assigned to.

3. In Properties, open the Widget dropdown and pick the avatar user entry.

New person fields are created as regular Many2one fields pointing at Users first, then switched to this widget the same way.

Studio sets the widget; the behavioral options stay XML-only.

Blocking user creation from the dropdown needs no_create; you rarely want a salesperson accidentally creating a login from a typo.

Making the avatar clickable in list views needs an explicit no_open: False, because outside the form view the link is disabled by default, a behavior specific to this widget.

Filtering which users are offered, for example only members of the project, is a domain on the field.

Standard assignee field

<field name="user_id" widget="many2one_avatar_user"/>

List column, avatar clickable

<field name="user_id"
       widget="many2one_avatar_user"
       options="{'no_open': False}"/>

Without the explicit option, clicking the avatar in a list does nothing; this is the widget's own default, not a bug.

Locked-down assignee, no accidental user creation

<field name="user_id"
       widget="many2one_avatar_user"
       options="{'no_create': True}"
       domain="[('share','=',False)]"/>

The domain limits the dropdown to internal users, excluding portal accounts, and no_create stops typos becoming user records.

Delay the search on large user tables

<field name="user_id"
       widget="many2one_avatar_user"
       options="{'search_threshold': 2}"/>

The command palette integration is wired in the component itself, verified in the source: when the view type is form or list, the widget calls useAssignUserCommand, which registers the Assign to me entry for the current record's field.

What that means in practice: with a task open, Ctrl+K (or Cmd+K) then typing "assign" offers Assign to me, and selecting it writes your user into the field, no mouse involved. In list views it applies to the focused row, which is what makes queue triage fast.

Two boundaries worth knowing. The command registers only on form and list views, not kanban, again straight from the source's viewType check. And it assigns the current user; "assign to my teammate" is still a dropdown interaction.

Presence, the green or grey dot, comes from Discuss (the mail module's presence service), so if a database somehow runs without mail, the widget family is not available at all; it lives in that module rather than in web.

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.

Avatars get cache-busting. The development version declares the user's write_date as a related field and keys the avatar URL on it, so when someone updates their profile photo, every view shows the new photo immediately instead of a stale cached one. A small change, but it closes a long-standing "the avatar didn't update" annoyance.

Options and registration are otherwise unchanged: the inherited many2one option set is the same and the widget keeps its name, so existing views should carry over untouched. Internals move to the new Owl props system, which only affects JavaScript patches. We re-verify this page against the shipped release before updating the table above.