Odoo Changelog — 2025-10-31

Friday, October 31, 2025

2 changes · saas-18.4

Improvements(2)

Enhancements to existing features

[IMP] voip: reduce idle registrations

Enterprisesaas-18.4voipMedium

VoIP sessions now try to sign out automatically when a browser tab is closed and expire sooner if that does not happen. This helps prevent users from hitting provider limits caused by multiple open or recently closed Odoo tabs.

Original PR description

Some providers like OnSIP allow for a limited number of registrations per user. This is a problem in Odoo because each tab opened creates a new registration for one hour.

This commit mitigates the problems in two ways:
- Sends an "unregister" request onbeforeunload to try to invalidate the registration upon closing the tab.
- Reduces the TTL of registrations so that they get invalidated quicker in case the unregistration failed.

Forward-Port-Of: odoo/enterprise#98413
Forward-Port-Of: odoo/enterprise#97963

#voip#registrations#browser-tabs

[PERF] hr_recruitment: Speed-up recruitment views

PR #233971

Coresaas-18.4hr_recruitmentMedium

Recruitment screens now load much faster by simplifying how eligible users are determined for job records. This reduces page processing time and response size, making the Recruitment app feel more responsive, especially for companies with many users.

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

Some providers like OnSIP allow for a limited number of registrations per user. This is a problem in Odoo because each tab opened creates a new registration for one hour. This commit mitigates the problems in two ways: - Sends an "unregister" request onbeforeunload to try to invalidate the registration upon closing the tab. - Reduces the TTL of registrations so that they get invalidated quicker in case the unregistration failed. Forward-Port-Of: odoo/enterprise#98413 Forward-Port-Of: odoo/enterprise#97963

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