Friday, October 31, 2025
2 changes · 19.0
Enhancements to existing features
The Phone app now opens much faster for HR officers by improving how access checks are handled behind the scenes. This reduces waiting time dramatically on large databases while keeping the same access behavior for users.
Original PR description
Description ----------- The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`. To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM. This leads to a few more queries, but each is fast and trivial to process. Benchmark --------- On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took: | Before | After | Speed-up | |--------|-------|----------| | 13.3s | 80ms | 162x |
HR users can open the Phone app much faster on large databases. The access check was optimized to avoid slow database scanning, reducing load times from seconds to milliseconds in the benchmark.
Original PR description
Description ----------- The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads…
Description ----------- The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`. To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM. This leads to a few more queries, but each is fast and trivial to process. Benchmark --------- On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took: | Before | After | Speed-up | |--------|-------|----------| | 13.3s | 80ms | 162x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr