hr_department_chart

A department record on its own tells you very little: a name, a manager, a parent. What people actually want from it is the shape around it, which departments sit above and which below.

This widget draws that shape on the form. It asks the server for the hierarchy around this department and renders it, with each level clickable.

Clicking one does not navigate to that department: it opens that department's employees, which is usually the reason someone was looking at the chart.

Department structure is one of those things everyone assumes is documented and usually is not. Putting the chart on the record makes the structure self-documenting, and makes a wrong parent obvious to whoever opens it.

Worth checking during implementation: whether your department tree models reporting or cost centers. Odoo uses it for both, and if those differ in your organization one of the two will be wrong on this chart.

Placing it

<widget name="hr_department_chart"/>

No attributes. It reads the department from the record.

What builds the chart

hr.department.get_department_hierarchy(id)

One call, the whole structure.

What a click does

action_employee_from_department(id)
# then the returned action is opened

Employees, not the department record.

Two lifecycle hooks fetch the hierarchy: one before the first render, and one whenever the props change. The second is easy to overlook and is what makes the chart correct when a user pages through departments in a list view without the component being destroyed between records.

The fetch itself is a single call taking the department identifier and returning the whole structure. Everything the chart draws, parents, children, counts, comes from that one payload, which keeps the render cheap and the browser ignorant of how the tree is computed.

The click handler is the other server round trip. Rather than constructing a window action with a domain, it asks the model for an action for that department and opens whatever comes back. That indirection is what allows the server to apply record rules, add context, or return a different view type without the widget changing.

Note that the click asks the model the widget is placed on rather than the department model directly, which matters if the widget is ever reused on a different form.

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

Reworked. The development branch updates the component to the newer state and lifecycle conventions. The hierarchy call and the click action are what to expect to survive.