selection_badge_with_filter

This widget extends selection_badge and overrides one getter. Instead of returning every value in the selection, it returns only those that appear in another field on the same record:

get options() {
    const allowedSelection = this.props.record.data[this.props.allowedSelectionField];
    return super.options.filter(([value, _]) => allowedSelection.includes(value));
}

That companion field is named by the allowed_selection_field option. It is typically a computed field that works out which states are reachable from where the record currently is.

Everything else, including the badge rendering and the size option, comes from selection_badge unchanged.

This solves a real workflow problem. A status field may have eight values, but from where a record sits today only three are legal. Showing all eight invites a user to pick an invalid one and then meet a server error.

Filtering at the widget means users only ever see the transitions that are allowed right now. The rules stay in Python, where they belong, and the interface simply reflects them.

If you are running Odoo 19 and using this pattern, read the Odoo 20 section before you upgrade. The behavior does not merely change; the name points at a different widget.

The standard Odoo 19 use, on the server action state field:

<field name="allowed_states" invisible="1"/>
<field name="state" widget="selection_badge_with_filter"
       options="{'size': 'sm', 'allowed_selection_field': 'allowed_states'}"/>

The companion field must be in the view and must hold a list of selection keys. The Odoo 20 equivalent of the same field:

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

This is the most consequential finding on this page, and it is the kind of change that does not show up in a release note.

In Odoo 19, selection_badge_with_filter is registered in the web module. It is generic: give it any selection field and any companion field holding allowed values, and it filters.

In Odoo 20, the registration key is gone from web and reappears in hr_holidays, attached to a different class built on a different base widget:

export class HrHolidaysBadgeSelectionWithFilterField extends BadgesSelectionField {
    get options() {
        const { name, record } = this.props;
        const forceFullDuration = record.context?.force_full_duration;
        const isHalfDay = record.data.work_entry_type_request_unit === "half_day";
        const allOptions = super.options;
        if (forceFullDuration && name === "request_duration" && !isHalfDay) {
            return allOptions.filter(([value]) => value === "full");
        }
        return allOptions;
    }
}

It no longer reads allowed_selection_field at all. Its filtering is hardcoded to leave requests: a context flag, a field named request_duration, and a half-day check.

So a custom view carrying the Odoo 19 XML will, after an upgrade, resolve to a widget that ignores your option and applies unrelated logic. If hr_holidays is installed, you get the leave widget. If it is not, the registration does not exist at all and the field falls back. Either way, the filtering you built stops working, and nothing errors to tell you.

Odoo migrated its own use to badges_selection, and that widget reads allowed_selection_field in its extractProps, still without declaring it. The size option was dropped from the standard view in the process. That migration path is the one to follow.

Treat this as a breaking change even though nothing errors.

The generic widget is gone from web. The registration name selection_badge_with_filter now belongs to an hr_holidays widget with hardcoded leave-duration logic that ignores allowed_selection_field. The supported type declaration changes too, since it inherits from badges_selection rather than badge_selection.

Odoo's own view moved to widget="badges_selection" with options="{'allowed_selection_field': 'allowed_states'}" and dropped size. Do the same in your custom views as part of the upgrade, and check every one of them, because a search for the widget name will still find matches that now mean something different.