Odoo Changelog — 2025-10-31

Friday, October 31, 2025

2 changes · saas-18.2

Improvements(2)

Enhancements to existing features

[IMP] hw_drivers: remove crypt library usage

Coresaas-18.2hw_driversiot_box_imageMedium

This update keeps Odoo IoT box setup working on newer Python and Raspberry Pi system versions. It also preserves access to relocated setup files and ensures Wi-Fi settings are saved where current system tools expect them.

Original PR description

To ensure compatibility with python 3.13+, we updated the method to generate the rpi's password to avoid using the removed `crypt` lib.

We also ensure that files moved between `point_of_sale/tools/posbox/`, `addons/iot_box_image/` and `setup/iot_box_builder` can still be found by system processes using symlinks.

In addition, we ensure that Wi-Fi configuration is saved to the right path, nmcli saving path changed in latest versions. (see: https://github.com/raspberrypi/trixie-feedback/issues/3). 

Forward-Port-Of: odoo/odoo#233676
Forward-Port-Of: odoo/odoo#233423

#iot#raspberry-pi#wifi#compatibility

[PERF] hr_recruitment: Speed-up recruitment views

PR #232354

Coresaas-18.2hr_recruitmentMedium

Recruitment pages now load much faster by avoiding unnecessary user-list processing in job views. This improves responsiveness for companies with many users while preserving the expected 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 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

To ensure compatibility with python 3.13+, we updated the method to generate the rpi's password to avoid using the removed `crypt` lib. We also ensure that files moved between `point_of_sale/tools/posbox/`, `addons/iot_box_image/` and `setup/iot_box_builder` can still be found by system processes using symlinks. In addition, we ensure that Wi-Fi configuration is saved to the right path, nmcli saving path changed in latest versions. (see: https://github.com/raspberrypi/trixie-feedback/issues/3). Forward-Port-Of: odoo/odoo#233676 Forward-Port-Of: odoo/odoo#233423

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