Friday, October 31, 2025
12 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
Resolved issues and error corrections
Point of Sale invoices linked to orders can no longer be reset to draft, avoiding a situation where an unposted invoice prevents the cash register session from closing. Users are guided to use a refund or credit note instead, keeping end-of-day operations smoother and more reliable.
Original PR description
Before this commit, it was possible to set the invoice of a PoS order to draft, which could prevent closing the session since unposted invoices block the session closing. This commit prevents that by raising a user error suggesting to refund the order or create a credit note instead. opw-5079889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232566 Forward-Port-Of: odoo/odoo#232464
Purchase orders now prevent deletion of a unit of measure that is still referenced by a purchase order line. This avoids confirmation failures and keeps purchasing workflows stable when units are being managed.
Original PR description
When a user deletes the UoM used in a purchase order line and then tries to confirm the purchase order. Steps to reproduce: --- - Install `purchase_stock` module(without demo) - Create a New PO > Add a product in Line (with UoM=Units) - Remove UoM in order line and select `Dozen` in it > Save - Settings > Units of Measure Categories > Open `Units` > Remove `Dozen` - Orders > Requests for Quotation > Open PO > `Confirm Order` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0` This error occurs because, after the UoM is deleted, the `product_uom` field becomes empty, which leads to an error. Solution: --- This commit resolves the error by restricting the deletion of a UoM when it is still in use. sentry-6746792383 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233783 Forward-Port-Of: odoo/odoo#231478
Users importing Indian IRN invoice JSON files no longer need extra company record permissions for the import to complete. This prevents a permissions error during invoice import and helps affected users continue their billing workflow without administrative access changes.
Original PR description
When importing an IRN JSON as an invoice, users without sufficient access rights to `res.company` fields encountered an access error on `l10n_in_edi_production_env`. This commit uses `sudo()` to safely read the company’s EDI environment configuration without requiring extra permissions. Before this PR: Import failed with error: `You do not have enough rights to access the field 'l10n_in_edi_production_env' on Companies (res.company)` After this PR: Import proceeds successfully for users without `res.company` read rights.
The Point of Sale now checks that its local browser database has all required data tables when it starts. If any are missing, it automatically updates the database setup, preventing sessions from failing after modules such as restaurant add new data needs.
Original PR description
Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code. If a new module (e.g.,…
Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code. If a new module (e.g., restaurant) adds a new object store to the PoS database schema but the `dbVersion` is not bumped, the store is never created. This causes the PoS session to fail when it tries to access the missing store. This commit modifies the `databaseEventListener` to add a check inside the `onsuccess` handler. After the database opens, it compares the list of required stores (`this.dbStores`) with the list of existing stores (`this.db.objectStoreNames`). If a mismatch is detected: 1. The current database connection is closed. 2. The `dbVersion` is incremented. 3. The database connection process is re-run. This forces the `onupgradeneeded` event to trigger, which then correctly creates the missing object stores, ensuring the database schema is always up-to-date. opw-5166049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Warehouse users can now open receiving lists more reliably when transfers include many quality checks. The change reduces memory use during quality check status calculations, avoiding worker crashes in large-volume inventory operations.
Original PR description
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive"…
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker. This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop. For a specific customer (opw-5025162), this was the case. Benchmarks: | No. stock.picking | avg no. quality checks | peak memory before | peak memory after | | ----------------- | ---------------------- | ------------------ | ----------------- | | 25 | 20 | 2771 mb | 235 mb | opw-5025162 Forward-Port-Of: odoo/enterprise#95568
This update fixes website builder scrolling behavior so footer animations appear correctly and newly added FAQ horizontal entries are brought into view. It improves the editing experience by making these visual elements behave as expected when pages require scrolling.
Original PR description
[FIX] website: get scroll from document element for footer animation __Current behavior before commit:__ Since [this PR], the scrolling is not done on `#wrapwrap` anymore. Now when an animation is…
[FIX] website: get scroll from document element for footer animation __Current behavior before commit:__ Since [this PR], the scrolling is not done on `#wrapwrap` anymore. Now when an animation is set on an element inside the footer it will not appear if a slideout effect is set on it. __Description of the fix:__ Get `scrollTop` and `scrollHeight` from the document element instead of `#wrapwrap` and add a test tour. __Steps to reproduce:__ 1. Open the Website builder. 2. Click on a column in the footer. 3. Set an "On Appearance" Animation on it. 4. Set the footer Slideout Effect to "Slide Hover". 5. Add some content on the page so that it's needed to scroll for the footer to be visible. 6. Save. 7. Scroll to the footer. => The column doesn't appear. [this PR]: https://github.com/odoo/odoo/pull/98429 --- [FIX] website: scroll on new entry in faq horizontal __Current behavior before commit:__ Since [this PR][1], the scrolling is not done on `#wrapwrap` anymore. Now when adding a new entry to the snippet faq horizontal, the page doesn't scroll automatically to the new entry. This behavior has actually never worked because [the PR that introduced faq horizontal][2] was merged just after [the PR that moved the scrolling to the document element][1]. __Description of the fix:__ Get `scrollTop` and `scrollHeight` from the document element instead of `#wrapwrap` and add a test tour. __Steps to reproduce:__ 1. Open the Website builder. 2. Drag a Text block 3. Choose the FAQ horizontal snippet 4. Click on "Add New" => The page doesn't scroll to the new entry. [1]: https://github.com/odoo/odoo/pull/98429 [2]: https://github.com/odoo/odoo/pull/176438 Forward-Port-Of: odoo/odoo#233850 Forward-Port-Of: odoo/odoo#228396
Odoo updates Peppol participant lookup handling to stay compatible with upcoming network rule changes that retire the old DNS method. Lookups are now routed through Odoo's IAP service, helping keep electronic invoicing connectivity reliable as Peppol requirements evolve.
Original PR description
From November 1st, CNAME DNS will be deprecated for Peppol lookups. From February 1st CNAME lookups will no longer be supported. The replacement are NAPTR DNS records. Multiple solutions were available, such as using DoH (e.g. with cloudflare DNS), but we ended up choosing to proxy DNS requests through IAP to centralize the lookups and make such specs upgrades easier to handle in the future. IAP is now responsible of doing the DNS lookup and fetching the service groups of the found SMP. IAP-side: https://github.com/odoo/iap-apps/pull/1227 task-5179969 Forward-Port-Of: odoo/odoo#233272 Forward-Port-Of: odoo/odoo#232483
VAT return check refreshes are faster after removing a slow duplicate check and replacing it with a clearer warning on reports with negative amounts. Access rules for company branches were corrected so users can view and refresh returns appropriately, while submissions require access to the full company structure.
Original PR description
The "No negative amount in VAT report" return check was too slow, we removed it and clean the database. On the other hand, refreshing checks had issues with the access rights when there was company branches. task-id: 5145537
Invoices created from Point of Sale orders can now be reset to draft when changes are needed, instead of being blocked. Users will see a warning notification, which supports local requirements where invoices must be adjusted before submission to government systems.
Original PR description
After this commit, it becomes possible to make an invoice linked to a PoS order draft, showing only a warning notification instead of blocking the action. This is required in some localizations where invoices must be modified before being sent to the government. opw-5218715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233649
The Helpdesk website "Browse Articles" button now sends portal users directly to the linked Knowledge article instead of an empty Knowledge home page. This ensures customers can reach the intended support content without confusion or extra navigation.
Original PR description
To reproduce: ============= 1. Create a Helpdesk Team linked to a Knowledge Article 2. Access the Help page on website as a portal user 3. Click on "Browse Articles" button -> redirected to empty knowledge home portal view Problem: ======== before this commit, redirection was made through the method `redirect_to_article` which will later call `_redirect_to_portal_view` that doesn't use the `article` parameter anymore as there is a patch on the front side to handle the redirection to the articale through the router, but as the calls are server-side, the patch is not applied and the redirection fails. Solution: ========= instead of calling `redirect_to_article`, directly redirect to the article's `website_url`. opw-5114885 Forward-Port-Of: odoo/enterprise#98363