many2many_tags_avatar

When the related records are people, a name-only pill wastes the fastest recognition channel humans have. The many2many_tags_avatar widget extends the standard Tags field so each pill renders the record's avatar_128 image before the name: survey interviewers, livechat operators, task collaborators. The autocomplete dropdown shows the same avatars while searching, so picking the right Ajay out of three is a face-match rather than a surname-match.

The file ships three registrations tuned per view. The base widget renders all pills. List views swap in a variant that shows at most 5 before collapsing the rest behind a "+N" counter, and kanban cards get a 3-pill variant where clicking opens a search popover for assigning people directly on the card.

Assignment fields are the highest-traffic relational fields in most Odoo deployments: who is on this task, who interviews this candidate, who owns this ticket. Rendering them as faces cuts the scan time on a busy kanban board to nearly nothing, and the quick-assign popover is the difference between dragging cards to a colleague's attention and assigning them without leaving the board.

One behavior deserves a policy decision before rollout: the kanban popover saves immediately. Add a person on a card and the record writes then and there, with no draft state. That is right for dispatch-style boards, but it also means a mis-click assigns someone for real, notifications included if the model sends them. Teams that want deliberate assignment should keep editing on the form view, where normal save semantics apply.

Note the model side too: whatever the pills point at needs an avatar_128 field. Users, employees, partners and channels have one. A custom model of, say, review committees does not, unless you inherit the avatar mixin.

Odoo Studio gets you most of the way, with one catch at the end.

1. Open the form in Studio and drag a Tags field from the Add a field panel onto the layout.

2. Point it at a people model such as Users or Employees when Studio asks for the relation.

3. Select the field and open Properties. The default widget is Tags, which renders plain pills without faces.

4. To get the avatar variant, turn on developer mode first: the widget picker then lists technical widgets, and you can choose many2many_tags_avatar. Without developer mode, the avatar variant is not offered for a generic tags field, and the change belongs in XML.

Everything the plain Tags field cannot do in Studio applies here unchanged: restricting the selectable people with a domain, blocking creation with no_create, or making the list depend on another field all need view-level work.

Two avatar-specific limits come on top. The image is hardcoded to avatar_128, so pointing the widget at a model without that field leaves broken image placeholders, and no Studio switch changes the source field. And the per-view pill limits, 5 in lists and 3 on kanban cards, are class constants in the source with no option to override them.

Interviewers on a survey, as core ships it

<field name="restrict_user_ids"
       widget="many2many_tags_avatar"/>

Assignable people, locked to existing users

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

Internal users only, no accidental partner creation from a typo. This is the configuration most assignment fields should ship with.

Delaying search on large user bases

<field name="member_ids"
       widget="many2many_tags_avatar"
       options="{'search_threshold': 2}"/>

Inherited from the Tags field: no query fires until two characters are typed, which is worth setting on databases with thousands of users.

The kanban variant is really three cooperating pieces, and knowing them explains its quirks.

The popover is its own registered widget. many2many_tags_avatar_popover wraps the field with save-on-change behavior: every add or delete calls record.save({ reload: false }) immediately. The kanban tags list opens that popover when clicked, passing canCreate: false, canCreateEdit: false and canQuickCreate: false hardcoded, which is why no create option you set ever resurfaces creation inside the card popover.

Pill order flips on cards. Both the kanban variant and the popover reverse the tag list, so the most recently added person renders first where space is tightest.

The command palette knows about this widget. extractProps sets withCommand on form and list views, wiring the assign-to-me style palette commands. On kanban the popover takes over that role instead.

The avatar URL is built with imageUrl(relation, resId, "avatar_128"), one image request per pill, served from the standard image route with access rights applied. If the browsing user cannot read the related record's image, the pill falls back to the placeholder silently.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. Everything below is read from the public development branch, which stays unstable until feature freeze; we re-verify this page against the shipped release.

The kanban registration is renamed to card.many2many_tags_avatar as part of the web client's kanban-to-card overhaul, and the standalone popover registration disappears: the popover becomes an internal class the card variant references directly. Views that referenced many2many_tags_avatar_popover as a widget name will need review.

Avatar URLs gain cache busting. The widget adds write_date to its fetched fields and appends it to the image URL, so changed profile photos show up without a hard refresh, matching what many2one_avatar_user got in 19.

Pill limits move into props. The hardcoded visible-item constants become a tagLimit prop, with the list default at 5 and the card default at 2, and the popover shows all. A new AvatarTag component replaces the tags-list templates, and the delete cross renders only when the field is editable.