many2many_checkboxes

Tags and dropdowns hide the options a user did not pick. For some decisions that is wrong: choosing warehouse routes on a product, meal categories on a lunch supplier, or EDI formats on a journal is a decision about the whole set, and the user should see every possibility while making it. The many2many_checkboxes widget renders exactly that: every record of the related model that matches the field's domain, as a checkbox list, ticked where a link exists.

There is no search box, no "create", no pagination. That austerity is the design: the widget assumes the choice space is small and stable, and in exchange the user gets the complete picture in one glance.

The checkbox presentation changes user behavior in a way worth exploiting. With tags, users pick what they remember exists; with checkboxes, they audit the full list every time. For configuration-flavored choices, which routes, which document types, which booth options, that audit moment prevents the "nobody knew that option existed" class of misconfiguration entirely.

The flip side is a hard scaling rule. The widget loads every candidate up front and silently shows at most 100, so it belongs on relations that stay small by nature. Our sizing rule from implementations: a dozen options is ideal, thirty is tolerable on a wide form, beyond that switch to tags and let search do the work. If the option list is user-extensible, it will not stay small, and checkboxes are the wrong bet.

This is one of the widgets Studio exposes cleanly.

1. Open the form in Studio and select an existing many2many field, or drag a Many2Many field onto the layout and pick the related model.

2. Open Properties on the right and set Widget to Checkboxes.

3. Optionally set a Domain in the same panel to trim which records appear as boxes, for example only active ones.

What Studio configures here is nearly everything the widget can do, because the widget itself is optionless. The limits are the widget's own: no way to enable search or creation, no way to raise the 100-record cap, no columns or grouping control for long lists, and no one2many support at all. If any of those are requirements, the fix is a different widget or a custom one, not more configuration.

Product routes, as core ships it

<field name="route_ids" widget="many2many_checkboxes"/>

Trimmed to relevant options with a domain

<field name="category_ids"
       widget="many2many_checkboxes"
       domain="[('active', '=', True), ('company_id', 'in', [company_id, False])]"/>

Only active, company-relevant records render as boxes. The same domain keeps the candidate count under the cap.

Defaults for records created from the list

<field name="tag_ids"
       widget="many2many_checkboxes"
       context="{'lang_filter': 'en'}"/>

The context is passed into the record-loading call, useful when the related model's name_search behaves contextually. The widget itself never creates records.

Two implementation choices explain the widget's feel in daily use.

The 100-record ceiling is inherited, not chosen. The list is fetched with name_search("", domain) and no limit argument, so Python's default limit=100 applies. Records beyond it are not rendered, with no indicator that anything is missing. If users report a checkbox "disappearing", count the candidates first.

Changes are batched deliberately. Each tick goes into a pending add or remove set, and a 500ms debounced commit folds them into one addAndRemove call. The component also commits on unmount and when the record model demands local changes, so nothing is lost by clicking Save quickly. The payoff is fewer onchange recomputations on models with heavy onchange logic, which is exactly the configuration-model territory this widget lives in.

A last detail: isEmpty is hardcoded false, so the widget always renders its list even when nothing is ticked. An empty checkbox list on the form means the domain matched no records at all.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below are read from the public development branch, which is unstable until feature freeze; we re-verify this page after release.

The widget's contract survives, its plumbing does not. The load moves from name_search to the newer web_name_search RPC with an explicit display-name specification, and it gains offline resilience: on a lost connection it falls back to rendering the records already linked instead of erroring. The batched commit switches from an add-and-remove call to explicit link and unlink commands that carry display names, and the widget starts declaring display_name in relatedFields.

Nothing option-related changes, because there are still no options. The 100-record behavior depends on the new RPC's server-side default; we will verify the effective cap against the release.