hr_org_chart

Open any employee in Odoo's HR app and the form ends with an Organization Chart: the chain of managers above the person, the person, and their direct reports, each row showing an avatar, a name, a job title and a count of direct and total subordinates. All of that is a single field widget named hr_org_chart.

It is an unusual field widget. It declares no options and no supported field types, and it never reads the value of the field it is attached to. Core mounts it on the child_ids one2many with readonly="1" and nolabel="1", but the field is only an anchor point in the layout. The component watches the record itself: it takes the record id and the parent_id field, calls its own HTTP route /hr/get_org_chart, and renders whatever the controller returns.

The org chart answers the questions HR and managers ask most while looking at a person: who does this employee report to, who reports to them, and how big is their team really. The direct and indirect counts are clickable, so a department head can jump from any employee to a kanban of that person's whole reporting line in one click, without building a filter.

Because the chart re-renders live as parent_id changes, it is also the fastest sanity check during reorganizations: change the manager field, and the chain above the employee redraws before you save. Companies that keep parent_id clean get an always-current org chart for free on every employee record, which is usually the moment teams stop maintaining a separate spreadsheet org chart.

How core mounts the chart

<field name="child_ids" widget="hr_org_chart"
       readonly="1" nolabel="1"
       class="position-relative w-100"/>

From hr_org_chart/views/hr_views.xml. The field could be almost any field of the model; the widget only uses the record's id and parent_id.

Adding the chart to a custom employee-like model

<!-- Only works for models the /hr/get_org_chart controller understands -->
<field name="parent_id" invisible="1"/>
<field name="child_ids" widget="hr_org_chart" readonly="1" nolabel="1"/>

The controller resolves employees through hr.employee, so on anything that is not an employee model you must extend /hr/get_org_chart server side first.

Two behaviors in the 19.0 source are worth knowing before you customize anything.

The res.users regression. In Odoo 17 and 18 the component carried an explicit fallback, documented in a source comment: on a res.users form it read employee_id and employee_parent_id from the record; on employee forms it read resId and parent_id. Odoo 19 removed that fallback and now reads only record.resId and record.data.parent_id. Place the widget on a user form in 19 and it treats the user id as an employee id, which silently renders the wrong chart or none at all. If you had an 18 customization showing the chart on user preferences, that is the line that broke it.

The refresh contract. A useRecordObserver watches the record and refetches when either the employee id or the parent changes, resetting the level cap each time. Clicking the more managers link sets the cap to 100 and forces a refetch, so the full chain is always one click away regardless of depth. Every avatar opens a popover component, and both the popover and the rows redirect through hr.employee.get_formview_action, so access rules keep applying to navigation.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We read the widget on the public development branch at the time of writing; the branch is unstable and this page will be re-verified after release.

The headline change is structural: the whole hr_org_chart module is deleted and the widget, its controller and templates move into the hr module under the same widget name. Templates rename from hr_org_chart.* to hr.*, so template inheritance breaks even though views keep working. Behavior also moves: chart data lands in reactive state guarded by a fetch counter against out-of-order responses, the RPC gains a disk cache with a stale-while-revalidate callback, the chart now also refetches when job_title is edited, and record navigation switches from get_formview_action to a new get_record_default_action method.