Friday, October 31, 2025
2 changes · saas-18.3
Enhancements to existing features
Recruitment pages now avoid loading large hidden user lists, making key views open much faster. This improves responsiveness for recruiters, especially in databases with many users, while keeping the same company-based user selection behavior.
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…
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#232354Portal comments that include a rating are now treated as meaningful even when no written text is added. This helps customer reviews, course feedback, and rated chatter entries remain visible and editable instead of being ignored as empty messages.
Original PR description
*: portal, portal_rating, rating, website_slides task-5016995 Forward-Port-Of: odoo/odoo#230426 Forward-Port-Of: odoo/odoo#223515