actionable_errors

Electronic invoicing regimes fail for concrete, fixable reasons: a partner is missing a tax ID, a product needs an HSN code, a journal is not configured for the government platform. Odoo's older pattern was a wall of text in a banner. The actionable_errors widget replaces it with structured alerts. A compute method on the model assembles a JSON dictionary of current problems, and the widget renders each entry as a Bootstrap alert with its message and, where the entry provides one, a button that takes the user directly to the thing that needs fixing.

Severity is part of the data. Each entry can declare a level of danger, warning or info, and the widget sorts the stack so blocking problems always appear first. An entry that declares no level is treated as a warning.

The difference between "your invoice failed validation" and "this partner is missing a Peppol endpoint, click here to open the partner" is the difference between a support ticket and a ten-second fix. For companies rolling out e-invoicing, which as of 2026 is becoming mandatory across more of Europe, India and Latin America every year, this widget is what makes compliance errors self-serviceable by accountants instead of escalations to IT.

It is also a pattern worth stealing for your own workflows. Any process with a pre-flight checklist, such as quality gates before a delivery or completeness checks before an approval, can expose its problems the same way: one computed JSON field, one widget, and every error arrives with its fix attached. We have used exactly this pattern in client builds to replace pages of validation text with clickable checklists.

The view side, from the Greek EDI localization

<div class="m-0" role="alert" invisible="not l10n_gr_edi_alerts">
    <field name="l10n_gr_edi_alerts" widget="actionable_errors"/>
</div>

The Python side: one entry with a window action

alerts["partner_missing_vat"] = {
    "message": _("Some partners are missing a VAT number."),
    "level": "danger",
    "action_text": _("View Partners"),
    "action": {
        "type": "ir.actions.act_window",
        "res_model": "res.partner",
        "view_mode": "list,form",
        "domain": [("id", "in", partners.ids)],
    },
}

The widget splits view_mode into the views list the web client expects, so a compute method can return a plain server-style action dictionary without worrying about client format.

An entry that runs a method instead (Odoo 19 and later)

alerts["activate_edi"] = {
    "message": _("The journal is not configured for e-invoicing."),
    "action_text": _("Enable now"),
    "action_call": ["account.journal", "action_enable_edi", journal.id],
}

On click the widget calls the method over RPC and then triggers a soft_reload, so the recomputed alerts refresh and the fixed entry disappears without a full page reload.

Two design details are worth knowing before you build on this widget.

The sort is stable within a level. The widget sorts entries by mapping each level to its position in the internal order danger, warning, info. Entries sharing a level keep the order your compute method inserted them in, so you control the story the user reads top to bottom.

The component is reusable outside fields. The file exports a base ActionableErrors component that takes the error dictionary as a plain prop, and the registered field version is a thin subclass that reads the record instead. Core uses the base component inside other components, which means you can embed the same alert stack in a dashboard or wizard without inventing a JSON field for it.

One honest caveat: because there are no declared supported types, the widget will accept being placed on any field, and it will silently render nothing useful unless the value is a dictionary shaped like the entries above. The contract is entirely by convention.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We compare the shipped 19.0 file against the public development branch, which is unstable until feature freeze, and we re-verify this page after release.

For this widget the comparison is easy to report: the file is byte-identical between 19.0 and the development branch at the time of writing. The JSON contract, the severity sort and both action routes carry into Odoo 20 unchanged, which is good news for the growing set of localizations built on it.