dashboard_graph

Odoo's accounting dashboard shows one card per journal, and each card carries a small chart: a line for bank and cash balances over time, bars for the ageing of outstanding invoices. Those charts are not a graph view and not a report. They are a field.

The model computes a JSON string, stores it in a text field, and the kanban renders that field with this widget. The widget parses the string, hands it to Chart.js and draws a compact canvas with no axes, no legend and no interaction beyond a tooltip.

Which chart it draws comes from a graph_type attribute on the field element. The accounting dashboard sets it dynamically per card, so a bank journal gets a line and a sales journal gets bars, from the same field and the same widget.

The pattern is worth knowing because it is the cheapest way to put a real chart on a kanban card. There is no dashboard framework involved: a computed field, a JSON structure and one attribute. For a client who wants a sparkline on each project, warehouse or team card, this is the shape of the answer, and Odoo core has three variants of it already.

The constraint that shapes the work is that the data is computed server side. Any filtering, date range or currency decision happens in Python, not in the widget, so the chart shows what the model decided to show. That is good for performance, because the payload is tiny and cached with the record, and limiting for interactivity, because the user cannot change the range without a new server computation.

The sample-data flag deserves a mention in any demo. When it is set the line chart is drawn in faded colors and tooltips are switched off, so a prospect looking at a fresh database sees that the curve is illustrative rather than their data. It is a small honesty feature that is easy to lose when you copy the widget into a custom module.

The core usage

<field name="kanban_dashboard_graph"
       widget="dashboard_graph"
       t-att-graph_type="['cash', 'bank', 'credit'].includes(journal_type) ? 'line' : 'bar'"/>

The attribute is set with a QWeb expression, so each card picks its own chart type from the record's own data.

A fixed chart type

<field name="graph_data" widget="dashboard_graph"
       graph_type="line"/>

Simpler and just as valid when every card shows the same kind of chart.

The JSON the field has to contain

[{
  "key": "Balance",
  "is_sample_data": false,
  "values": [
    {"x": "01 Jan", "y": 1200, "label": "January",
     "value": 1200, "type": "past"}
  ]
}]

An array whose first element is used. Line charts read the x and y keys, bar charts read label, value and type.

Two details govern how this widget behaves in practice, and neither is documented.

The first is that the JSON is parsed once, in the component's setup, and stored on the instance. The redraw effect runs after every render, but it always redraws from that stored copy. So if the underlying field changes while the card is on screen, for example after a server-side recompute, the chart keeps drawing the old data until the component is recreated. On a dashboard that is reloaded wholesale this never shows; on a card that updates in place, it does.

The second is the sample-data handling, which differs by chart type. In a line chart, the flag fades both the border and the fill to a fraction of their opacity and disables tooltips. In a bar chart it only disables tooltips; the bars keep their normal colors. So a sample bar chart looks real, and a sample line chart does not.

The bar coloring is worth spelling out because it is the whole reason the bar variant exists. Each point carries a type, and the widget picks one color for past, another for future, and a neutral grey for anything else. On the accounting dashboard that is what separates overdue amounts from amounts not yet due, without a legend.

Both charts hide their y axis entirely and the line chart hides its x axis too, which is what makes them read as sparklines rather than as reports. The bar chart keeps an x axis with grid and label colors chosen for the active light or dark scheme.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this can still change; we re-verify the page after release.

The widget changes hands. Accounting stops using it: the development branch adds a dedicated accounting dashboard graph widget in the account module and the journal dashboard switches to it. The base widget stays in web, and on that branch its core user becomes the Point of Sale dashboard, with a fixed line chart type.

Internally it moves to a chart hook. The manual bundle loading, canvas reference and destroy effect are replaced by a shared hook that takes a configuration getter, and the props move to the new schema. The chart configurations themselves, the sample-data rules and the bar coloring are unchanged.