many2manyattendee

A meeting's attendee list has to answer more than who was invited. Who accepted, who declined, who has not replied, who has no email address to be invited at all, and who is already busy at that time. Rendering that as a plain list of names loses all of it.

This widget puts the answers on the avatars. It extends Odoo's avatar tags widget, so each attendee is a small round picture with their name, and adds a status icon to those who have responded: a tick for accepted, a cross for declined, a question mark for tentative. Attendees who have not replied simply have no icon.

Two further flags come from companion fields on the meeting: attendees whose email is invalid, and attendees who are unavailable because they already have something in the diary. The organizer is sorted to the front, so the first avatar is always the person who owns the meeting.

The value is entirely in the glance. Before a meeting, the question is usually whether enough of the right people have accepted, and answering it from a list of names means opening something. Icons on avatars answer it without a click, which is why this is the one place in Odoo where attendee status is rendered rather than reported.

The missing email flag is the operationally important one. An attendee with no valid address is not going to receive the invitation, and without a flag that only becomes apparent when they do not turn up. Surfacing it on the avatar puts the problem in front of the person who can fix it, at the moment they are already thinking about the invitee list.

The availability flag, added in Odoo 19, is the scheduling equivalent. It does not stop you inviting someone who is busy; it tells you before you send.

The core usage

<field name="partner_ids" widget="many2manyattendee"/>

No options. Everything the widget shows beyond the avatars comes from its own server call and from companion fields on the meeting.

The companion fields it reads

<field name="invalid_email_partner_ids" invisible="1"/>
<field name="unavailable_partner_ids" invisible="1"/>

Both are read by literal name with no declared dependency. Without them the avatars render, just without those two flags.

Restricting who can be added

<field name="partner_ids" widget="many2manyattendee"
       options="{'no_quick_create': True}"/>

Inherited from the tags widget. Useful where attendees should be existing contacts rather than typed names.

The status data does not come from the record. The widget registers a special data loader that calls a dedicated method on the partner model with the attendee ids and the meeting id, and gets back a list of attendee details including each one's response and whether they are the organizer. That is why the icons appear without any status field being present in the view.

The tags getter then decorates the inherited tag list. For each tag it finds the matching entry from that call and copies the status onto the tag, along with an icon class chosen from a small fixed map. It then checks the two companion fields and sets a no-email flag and an unavailable flag where the attendee appears in them.

The last step is the sort. If one of the returned entries is marked as the organizer, the list is reordered so that attendee comes first. The comparison used is a simple two-way test rather than a full ordering, so the remaining attendees keep whatever order they arrived in.

One small curiosity in the Odoo 19 source, shared with a couple of other widgets in core: the class spreads its own static components list inside its own class body. That resolves through static inheritance to the parent's value, which is what was intended, and the development branch replaces the whole components arrangement anyway.

The unavailable flag is the one genuine feature difference between Odoo 18 and Odoo 19: the second companion field and its handling are new in 19.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and the notes below can still change; we re-verify the page after release.

A different base. The widget is rebased from the generic avatar tags field onto the user avatar tags field from the Discuss module, which brings user-aware behavior such as opening a chat from an avatar.

A dedicated tag component. The custom attendee tag list is replaced by an attendee tag built on the shared avatar tag component, and the three status icons move from the older icon font to Odoo's own icon set.

Error handling. The development branch imports the connection-lost error type in this file, which suggests the attendee detail call is being made resilient to a dropped connection rather than failing the render.