many2many_avatar_user

Assignment fields answer one question at a glance: who is on this? This widget renders a many2many pointing at users as a row of round avatar pills, and it is what Odoo itself uses for Assignees on tasks, to-dos and recruitment stages.

Under the hood, the Odoo 19 source builds it as a layered widget: it extends the generic many2many_tags_avatar, which itself spreads the many2many_tags descriptor, then mixes in a user-specific chatter layer. That layering is why it inherits every tags option, and why it adds three user-only behaviors: an avatar card popover when you click a face, automatic assign-to commands in the command palette on form and list views, and a specialized autocomplete for picking users.

Four registrations cover the view types, and each renders differently: full pills with names on forms, compact avatars in lists and kanban cards, and the same compact treatment in the activity view.

Who-is-on-what is the single most-read piece of information on a project board. Avatars make it readable from across the room, and misassignments jump out in a way names in a column never do. That is the display half.

The workflow half is the kanban quick assign. Managers reassign work directly on the board: click the assign avatar on a card, pick people in the popover, done. Two properties of that flow, both verified in the source, matter operationally. Every change saves the record immediately, so there is no draft state and no accidental discard, and reassignments land in real time. And the popover deliberately blocks creating new users, so nobody accidentally invents an account while typing a name mid-assignment.

One sizing rule to plan around: kanban cards show three avatars before collapsing the rest behind a counter, lists five. On teams where six people genuinely share a task, the counter is what users will see, and hovering or opening the record is how they see everyone.

The Assignees pattern

<field name="user_ids" widget="many2many_avatar_user"/>

On forms and lists this also registers the assign commands in the command palette.

Restricted to existing users, delayed search

<field name="user_ids"
       widget="many2many_avatar_user"
       options="{'no_create': True, 'search_threshold': 2}"/>

Inherited tags options at work: no user creation from the field, and no query until two characters are typed, which matters on databases with thousands of users.

Scoped to project members via domain

<field name="user_ids"
       widget="many2many_avatar_user"
       domain="[('share', '=', False)]"/>

The standard field domain filters the picker, here to internal users only.

The variant behavior is where the source gets interesting.

List cells decide when to show names. The list variant renders avatar plus name only when the field holds exactly one user or the row is being edited; with several users it collapses to faces only, keeping columns narrow. The kanban variant goes further: names appear only while editing. Both rules are explicit getters in the source.

The kanban popover is a different editing model. Clicking quick-assign opens a popover running a popover-specific subclass whose update and delete paths call record.save() immediately after each change. It also opens with creation fully disabled, quick create and create-and-edit included, and a Search users placeholder. So board-side assignment is instant and closed, while form-side assignment follows the normal edit flow and honors your creation options.

The avatar card is relation-gated. The mixin shows the card popover only for res.users and res.partner relations, one card at a time. Point the widget at another model and clicking a face does nothing, with no error.

The activity view reuses the kanban descriptor. activity.many2many_avatar_user is registered with the kanban variant, so activity cells behave exactly like kanban cards, quick assign included.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The following reads the widget and its bases on the public development branch, which is unstable until feature freeze; we re-verify after release.

Four movements are visible. The kanban registration is renamed: kanban.many2many_avatar_user becomes card.many2many_avatar_user, part of the repo-wide kanban-to-card prefix rename, and the activity registration now points at that card variant. Avatar URLs gain write_date cache busting through the base widget, so changed profile pictures show immediately. The visible-avatar caps move into a tagLimit prop with new defaults, 2 on cards and 5 in lists, with the popover showing all while editing. And the tag and avatar card components are rebuilt, AvatarCardPopover becomes AvatarCard, click handlers change name, so JavaScript patches against 19 internals will not survive unedited. View XML is untouched by all of this.