account_json_checkboxes

The Send wizard for invoices offers a changing set of choices: email, download, EDI channels that depend on the customer's country and configuration. Modeling every possible choice as a boolean field would mean schema changes each time a localization adds a channel. Odoo's solution is one fields.Json whose compute builds the choice set per record, and this widget to render it.

Each key of the dict becomes a checkbox. The entry controls everything about it: checked is the state, label the caption, readonly locks that single box while others stay editable, and question_circle, when present, renders a help icon whose tooltip is the string itself. Layout is a compact inline row by default, or one box per line with the stacked option.

State handling is live in both directions. Ticking a box mutates a local reactive copy and pushes the whole dict back to the record after a 100 millisecond debounce, so rapid clicking produces one update instead of five. And because the component observes the record, a server recompute, say, picking a different customer whose country enables another EDI channel, replaces the checkbox set on the fly.

The wizard this widget serves is one of the most-clicked screens in Odoo invoicing, and its design carries a lesson for anyone extending the system: when the option set is dynamic, put it in data, not in fields. A JSON dict computed per record means new sending channels, compliance toggles or feature flags appear without database migrations, and old ones vanish just as cleanly.

The per-key readonly flag is the underrated part. It lets the server enforce policy inside the choice set, a mandated e-invoicing channel arrives pre-checked and locked, while optional channels stay clickable. Users see the full picture including what they cannot change, which beats hiding the locked options and fielding why is EDI missing tickets.

We reuse this widget for configuration matrices in custom Odoo builds, checklists of integrations, per-partner document options, dynamic consent boxes, because it ships with core, needs zero JavaScript, and the entire UI is driven from one compute method. The only cost is that values live inside a JSON blob, so reporting on individual choices takes a lateral read rather than a plain field filter.

How core uses it (invoice Send wizard)

<field name="sending_method_checkboxes" widget="account_json_checkboxes"/>
<field name="extra_edi_checkboxes" widget="account_json_checkboxes"
       invisible="not extra_edi_checkboxes"/>

The value shape the widget renders

{
    "email": {"checked": true, "label": "by Email"},
    "peppol": {
        "checked": true,
        "label": "by Peppol",
        "readonly": true,
        "question_circle": "Required for this customer's country"
    }
}

A custom json field, stacked vertically

<field name="feature_checkboxes"
       widget="json_checkboxes"
       options="{'stacked': True}"/>

On the Python side, read the ticked keys the way core does: iterate the dict and keep keys whose entry has checked truthy. The wizard's sending_methods compute is exactly that loop.

The move that left a namespace fossil. The widget was born in Odoo 18 inside the account module. Odoo 19 promoted it to web, renamed it json_checkboxes, and kept account_json_checkboxes as a second registration of the same descriptor with the comment // TODO: remove in saas~19.1. The QWeb template, however, kept its original name: account.JsonCheckboxes, an account-namespaced template shipped by the web module. Harmless, but a giveaway of the file's origin, and a warning for anyone building template inheritance: inherit account.JsonCheckboxes, not a web-namespaced guess.

Two 18-era quirks were quietly fixed. In 18 the checkbox's disabled state was computed from the per-key readonly alone, so making the whole field readonly did not lock the boxes; 19 adds props.readonly || to the check. And 18's descriptor declared supportedTypes: ["jsonb"], a type that does not exist in Odoo's field system, corrected to json in 19. Neither ever broke the core wizard, which loads the field editable and json-typed anyway.

Reactivity details. The component seeds a reactive copy from the record, so it mutates locally, then debounces the write-back by 100 ms. The record observer merges server values into that same copy with Object.assign, which means keys removed by a recompute are merged over but new and changed keys arrive live. The Odoo 20 branch swaps the state primitive for the new proxy-based API and typed props with no behavioral change, and the alias registration, TODO comment included, is still there.

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

No functional change is visible. The development branch migrates the component to the new reactive-proxy and typed-props APIs, a framework-wide sweep, while the option, the value contract, the debounce and the template all stay as in 19.

The deprecated alias outlives its eviction notice. account_json_checkboxes is still registered on the branch, TODO comment intact, despite the comment scheduling removal for saas 19.1. Views using the old name will keep working in 20 as things stand, but the polite move during any version migration is to switch to json_checkboxes and stop depending on a name the source explicitly wants to delete.