grouped_view_widget

Some wizards need to show a table that does not exist yet. The Accrued Orders wizard is the canonical case: it computes the accrual entries it would create for the selected purchase or sale orders, and shows them for review before anything touches the ledger. Those lines are not records, so an embedded one2many is the wrong tool. Odoo's answer is to serialize the preview server side and render it client side, and grouped_view_widget is the renderer.

The widget reads the field's value, a plain string, runs JSON.parse on it, and renders a table styled like a grouped Odoo list: a header row built from options.columns, one shaded full-width row per group carrying group_name, then the item rows, each cell pulled from the vals dict by the column's field key with the column's CSS class applied. When the value is empty it renders nothing at all, and when the server capped the preview it prints a plain sentence: N are not shown in the preview.

There is no interaction anywhere: no sorting, no clicking, no editing. It is a picture of a table, deliberately.

The pattern this widget embodies is the interesting part: preview before commit. Accruals are exactly the kind of entry that is annoying to reverse, so the wizard shows the complete picture, grouped and totaled, while it is still free to cancel. If your team books accrued revenue or expenses at close, this screen is why the Odoo flow is safer than posting first and checking after.

For builders, the widget is a free, core-maintained way to put any computed table inside a wizard without creating transient records or a custom component. Approval previews, import dry-runs, payroll simulations, price recalculation summaries: compute a dict, json.dumps it into a Text field, point this widget at it. We reach for it in custom wizard work whenever a client asks to see what will happen before it happens, because the server stays the single source of truth and the client stays dumb.

The one discipline it imposes is honest truncation. The server decides how many rows the preview carries and reports the remainder through discarded_number, which keeps giant previews from freezing the browser while never hiding that lines were cut.

How core uses it (Accrued Orders wizard)

<field name="preview_data" widget="grouped_view_widget" class="w-100"/>

The JSON contract, minimal and complete

{
    "groups_vals": [{
        "group_name": "August 2026",
        "items_vals": [
            [0, 0, {"account": "Accrued Expenses", "amount": "1,250.00"}]
        ]
    }],
    "options": {
        "columns": [
            {"label": "Account", "field": "account", "class": ""},
            {"label": "Amount", "field": "amount", "class": "text-end"}
        ],
        "discarded_number": ""
    }
}

Note the row shape: each entry of items_vals is a three-element list and the widget reads index 2. Core emits o2m-command-style [0, 0, vals] triples so the same structure can seed real records later; a bare vals dict will not render.

Feeding it from a custom wizard

preview_data = fields.Text(compute="_compute_preview_data")

# in the compute:
record.preview_data = json.dumps({
    "groups_vals": groups,
    "options": {"columns": cols, "discarded_number": ""}
})

Format everything server side: amounts, dates and currency symbols arrive as display strings, because the widget applies no formatters of its own.

Values are strings, not JSON fields. The core field is fields.Text, and the widget's getValue does JSON.parse on every render, with an empty-structure fallback when the field is falsy but no error handling for malformed JSON. A truncated or hand-edited value throws in the template, so always emit via json.dumps, never string concatenation.

The group row styling is hardcoded. The shaded group header uses an inline background-color: #dee2e6 in the template rather than a CSS class, one of the few inline styles left in core widget templates. Restyling means overriding the template, not writing CSS.

A dead template ships in the same file. grouped_view_widget.xml still contains account.OpenMoveTemplate, an anchor bound to widget.value, the pre-16 legacy widget API. No component references it and the expression could not evaluate under the modern engine; it has simply survived every cleanup since, including on the current development branch.

History in one line. Odoo 16 cached the parsed value with onWillUpdateProps and registered the bare class; 17 moved to the parse-on-render getter and descriptor registration; 18, 19 and the development branch are byte-identical apart from a removed pragma and cosmetic template rewrites.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and as always we read the public development branch rather than speculate, with the caveat that the branch keeps moving until feature freeze and this page is re-verified after release.

For this widget the development branch shows no functional change whatsoever. The JavaScript is identical to 19, the template's only diff is the framework-wide rewrite to explicit this. expressions, the Accrued Orders usage is unchanged, and even the fossil account.OpenMoveTemplate is still there. Custom wizards feeding this widget should migrate without any attention.