hr_leave_stats

Approving a time off request is two judgments. Has this person already taken a lot this year, and will the team be covered while they are away. Neither is answerable from the request itself, so approvers historically opened two other screens.

This widget puts both on the request. One panel lists the employee's validated leave for the calendar year of the request. The other lists colleagues in the same department whose leave overlaps the requested dates.

Both refresh as the form is edited, so changing the dates immediately changes who shows up as a conflict.

The coverage question is the one that gets skipped, and it is the one that causes the problem. An approver looking at a single request has no way to know that two other people in the same team already booked the same week.

Configuring departments to match how work is actually covered is what makes this panel useful. If a department is too broad, the list fills with irrelevant names; too narrow and real conflicts are invisible.

Placing it

<widget name="hr_leave_stats"/>

No attributes. It requests the four fields it needs.

The employee query window

# the whole calendar year of the request start
start of year  ..  end of year

Not the requested dates.

The department query window

# exactly the requested dates, overlapping
date_from <= to   and   date_to >= from

And excluding the requesting employee.

The two queries use different windows, and that is the whole design. The employee list widens to the calendar year of the request's start date, because the question is about the year's pattern. The department list narrows to exactly the requested dates, because the question is about this week.

Both use an overlap test rather than containment, so a colleague whose leave merely touches the requested range still appears. That is correct for coverage: a partial overlap is still a day uncovered.

Reloading is driven by a record observer that compares the previous dates, employee and department against the new ones and only reruns the query whose inputs changed. Changing the dates reruns both; changing only the employee reruns only the employee list.

One small presentational detail: the department's display name arrives as a path, so the widget takes the last segment for display and keeps a flag recording that a parent existed, which lets the template show the hierarchy without printing the whole path.

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.

Substantially rewritten. The development branch reworks the component around the newer state and data conventions, with a large diff. The two panels and the two query windows are what to expect to survive; the details of how the data is loaded are being reshaped.