badges_selection

badges_selection renders a selection field as a row of clickable badges instead of a dropdown, so every choice is visible and selecting one is a single click.

It is built on a shared BaseBadgesField that it has in common with badges_many2one, which is why the two behave identically apart from where their choices come from.

The interesting part is the gap between what it declares and what it reads. The descriptor lists one supported option. Its extractProps reads five values from the options dictionary and a sixth from the field's required state.

Badges suit a short list that people set often: a stage, a priority, an approval state. A dropdown hides the options behind a click; badges put them on the screen and halve the interaction.

The filtering options are the ones worth knowing about, because they solve a problem most teams currently solve with Python. If a record's legal next states depend on where it is now, you usually compute that server-side and then fight the interface to reflect it. Here you compute the allowed list into a field and name that field in the widget. The badges follow.

Plain badges:

<field name="state" widget="badges_selection"/>

Showing only the states the record can legally move to. This is the pattern Odoo itself uses on server actions:

<field name="allowed_states" invisible="1"/>
<field name="state" widget="badges_selection"
       options="{'allowed_selection_field': 'allowed_states'}"/>

With icons, replacing the Odoo 19 selection_badge_icons widget:

<field name="state" widget="badges_selection"
       options="{'icon_mapping': {'draft': 'fa-pencil', 'done': 'fa-check'},
                 'default_icon': 'fa-circle-o', 'badge_limit': 5}"/>

Here is the whole configuration surface, quoted from the source:

extractProps: ({ options }, dynamicInfo) => ({
    defaultIcon: options.default_icon,
    badgeLimit: options.badge_limit,
    canDeselect: !dynamicInfo.required,
    iconMapping: options.icon_mapping,
    allowedSelectionField: options.allowed_selection_field,
    excludedSelectionField: options.excluded_selection_field,
}),

Compare that against the declared list, which contains exactly one entry, badge_limit. Four options are read and never announced.

The two filtering options are the significant ones. Each names another field on the same record whose value is a list of selection keys, and the widget narrows the badges accordingly. That is conditional choice filtering driven entirely from a view attribute, where the usual approach is a dynamic selection method in Python.

This is also the migration path from Odoo 19. That version had a separate widget, selection_badge_with_filter, whose allowed_selection_field option was likewise undeclared. Odoo 20 removed the generic version of that widget, recycled its name for an unrelated hr_holidays widget, and moved its own use here. In ir_actions_views.xml the Odoo 19 line reads widget="selection_badge_with_filter" options="{'size': 'sm', 'allowed_selection_field': 'allowed_states'}" and the Odoo 20 line reads widget="badges_selection" options="{'allowed_selection_field': 'allowed_states'}". The size option did not survive.

One more behavior worth knowing: canDeselect is derived from the field's required state rather than from an option. A non-required field lets a user clear the value by clicking the active badge again. A required one does not. There is no way to override that from the view.

Introduced in Odoo 20, replacing selection_badge from Odoo 19, which had 31 uses and is removed.

It also absorbs two widgets that were separate in Odoo 19. selection_badge_icons, which existed only to add icons, is replaced by the icon_mapping and default_icon options here. And the filtering behavior of selection_badge_with_filter moves here through allowed_selection_field.

Be careful with that last one. The name selection_badge_with_filter still exists in Odoo 20, but it now belongs to an unrelated hr_holidays widget with hardcoded leave-duration logic that ignores allowed_selection_field entirely. Migrating to badges_selection is the correct move; leaving the old widget name in place is not.