badges_many2one

A many2one normally renders as an autocomplete. badges_many2one renders it as a row of badges, one per candidate record, with the selected one highlighted. Picking is a single click.

It shares a BaseBadgesField with badges_selection, so the two look and behave identically. The difference is where the choices come from: a selection list there, a database query here.

That query is the part that makes this more than a styling choice. With no icon field configured it uses a plain name_search. With one, it switches to a search_read so it can fetch the icon alongside the name in the same round trip.

This suits a many2one with a small, stable set of records that people choose from constantly: a delivery method, a service level, a payment term. Those are relations rather than selections because someone has to maintain the list, but they behave like selections to the user, and a dropdown is friction for them.

The icon support is what makes it worth configuring rather than just enabling. If your target model already carries an icon or a class per record, each badge can show it, which turns a row of similar words into something readable at a glance.

Basic badges:

<field name="carrier_id" widget="badges_many2one"/>

With a per-record icon read from the target model, and a fallback:

<field name="carrier_id" widget="badges_many2one"
       options="{'related_icon_field': 'icon_class',
                 'default_icon': 'fa-truck', 'badge_limit': 6}"/>

A domain on the field still applies, so you can narrow the candidate list the usual way:

<field name="carrier_id" widget="badges_many2one"
       domain="[('active', '=', True)]"/>

Most relational widgets assume the server is reachable. This one does not, and the handling is explicit:

catch (error) {
    if (error instanceof ConnectionLostError) {
        const currentVal = record.data[name];
        if (!currentVal) {
            return [];
        }
        return [[currentVal.id, currentVal.display_name]];
    }
    throw error;
}

When the candidate query fails because the connection is gone, the widget does not throw and does not render an empty field. It falls back to a single badge showing whatever the record already holds, so the form still displays the truth about the record even though no new choice can be made. Any other error is rethrown normally.

That is worth knowing on tablets, warehouse terminals and anywhere else connectivity is unreliable. The field degrades to read-only rather than to broken.

The second detail worth planning around is that this widget loads the candidate list eagerly. It queries the co-model when the field renders, rather than when a user opens a dropdown. On a model with a handful of records that is free. On one with thousands it is a query per form open, and the badges would wrap into a wall anyway. Use badge_limit to collapse past a threshold, and reach for the ordinary many2one once the list stops being short.

For genuinely long lists the widget offers a Search More dialog, wired through useSelectCreate with creation disabled, so a user can find a record that is not on screen but cannot create one from here.

Introduced in Odoo 20. There is no Odoo 19 equivalent: this is new capability rather than a rename of something older.

It arrives alongside badges_selection, which does the same job for selection fields, and together they replace the single selection_badge widget that Odoo 19 had. That one handled only selection fields, so a many2one rendered as badges was not possible in Odoo 19 without a custom widget.