Odoo Changelog — 2025-11-03

Monday, November 3, 2025

1 change

Improvements(1)

Enhancements to existing features

[PERF] hr_recruitment: Speed-up recruitment views

Core19.0hr_recruitmenthrHigh impact

This change removes extra processing from the Recruitment app when opening job views, which makes pages load significantly faster and reduces the amount of data sent to the browser. It also keeps the earlier behavior fix so users are matched correctly even when a company is not set, while keeping an old field available for compatibility.

Original PR description

Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.

This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.

Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.

This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.

⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.

Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:

|                       | Before  | After  | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time  | 400ms   | 160ms  | 2.5x        |
| Frontend process time | 3.3s    | 220ms  | **15x**     |
| Total (LCP) time      | 3.7s    | 380ms  | 9.7x        |
| Response Payload size | ~800KiB | ~33KiB | **24x**     |

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#232354

#performance#recruitment#kanban#load-time#compatibility

Description ----------- The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies. This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field. Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead. Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring. This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do. ⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS. Benchmark --------- On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took: | | Before | After | Improvement | |-----------------------|---------|--------|-------------| | Backend process time | 400ms | 160ms | 2.5x | | Frontend process time | 3.3s | 220ms | **15x** | | Total (LCP) time | 3.7s | 380ms | 9.7x | | Response Payload size | ~800KiB | ~33KiB | **24x** | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232354