many2many_avatar_resource

This is the x2many form of the resource avatar widget. It builds on the user avatar tags widget from mail and layers resource awareness on top through a mixin applied to all three view variants.

The per-tag rendering is where the resource logic lives:

getTagProps(record) {
    return {
        ...super.getTagProps(...arguments),
        icon: record.data.resource_type === "user" ? null : "fa-wrench",
        colorIndex: record.data.color,
        img: record.data.resource_type === "user"
            ? `/web/image/${this.relation}/${record.resId}/avatar_128`
            : null,
    };
}

A human gets an avatar image and no icon. Anything else gets a wrench and no image. The color index comes from the resource record, so material resources are still distinguishable from each other.

On a planning or field service record that assigns a mix of people and equipment, this is what stops the two blurring together. A dispatcher scanning a board can see at a glance that a job has two technicians and a lift, rather than three names.

The detail that trips teams up is the hover card. It appears for people and not for machines, which is correct, but users read the absence as a fault. It is worth saying once: there is no card for a machine because there is nothing on a machine record worth showing in one.

On a field holding several resources:

<field name="resource_ids" widget="many2many_avatar_resource"/>

The view-specific variants are selected automatically by the view, so you never write the prefix yourself:

<!-- in a list view this resolves to list.many2many_avatar_resource -->
<field name="resource_ids" widget="many2many_avatar_resource"/>

The kanban variant carries one override that no option controls and no documentation mentions:

export class KanbanMany2ManyAvatarResourceField extends WithResourceFieldMixin(KanbanMany2ManyTagsAvatarUserField) {
    get tags() {
        return super.tags.reverse();
    }
}

The same record, with the same resources in the same order, renders one way in a form or list and the opposite way on a kanban card. It is intentional, presumably so the avatars stack correctly against the card's overflow counter, but from the outside it looks like a sorting bug.

This matters if anyone on your team compares a board against a list and concludes the data is inconsistent. It is not. Only the display order differs, and only in kanban.

A second detail worth knowing is why the autocomplete is custom. The widget replaces the standard search with its own search_read:

search(request) {
    return this.orm.call(
        this.props.resModel,
        "search_read",
        [this.getDomain(request), ["id", "display_name", "resource_type", "color"]],
        ...
    );
}

The default name search returns only an id and a label, which is not enough to draw the right icon before the tag is created. Fetching resource_type and color in the search means the dropdown itself can show a wrench next to a machine, rather than guessing and correcting after selection.

Two registration changes. kanban.many2many_avatar_resource is gone, replaced by card.many2many_avatar_resource, and a new activity.many2many_avatar_resource variant is added for the activity view.

The kanban rename is not specific to this widget: every one of the fourteen kanban. prefixed registrations in Odoo 19 became card. in Odoo 20, because Kanban records now render through a new Card renderer. Zero kanban. field registrations remain.

The base registration and behavior are unchanged, so ordinary views carry over. Custom code referencing the kanban. variant needs renaming.