Friday, October 31, 2025
19 changes · saas-18.3
Resolved issues and error corrections
The mail app’s automated test for searching discussion sub-channels now waits for the page state to settle before scrolling. This reduces false test failures under heavy system load and helps keep releases stable without changing end-user behavior.
Original PR description
The `test_discuss_sub_channel_search` tour ensures that lazy loading of threads works correctly with the search feature. Technically, the component uses the `useVisible` hook which waits for a trigger to be visible before loading more threads. However, under high CPU load, the `IntersectionObserver` might not detect the change. For example, clearing the search input will make the element disappear, but scrolling afterward may make it reappear. As a result, the component might not detect that it should load more threads. In practice, this should never happen. The test now waits for the state to update before scrolling. fixes runbot-181951 Forward-Port-Of: odoo/odoo#233419
The time off request form now only shows the document attachment field when supporting documents are enabled for that time off type. This prevents employees from seeing or using an irrelevant upload option and keeps the request process aligned with company configuration.
Original PR description
issue: - Field to attach documents is always visible when applying for time off regardless of whether we have allowed supporting documents in "time off types" or not <img width="641" height="505" alt="image" src="https://github.com/user-attachments/assets/0ec26822-5284-474f-b791-4b2b8e5eb9cc" /> <img width="511" height="265" alt="image" src="https://github.com/user-attachments/assets/ea546067-ac62-4e25-9a70-bbd86c053109" /> cause: - In commit [1], there was a change, which resulted to this issue [1] https://github.com/odoo/odoo/commit/944c11e61abead4f5157a7a7cb7b1f536bc14411 fix: - `supported_attachment_ids` now also depends on whether uploading files in a time off is supported or not opw-5144399 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
When a cashier loads a sales order in Point of Sale and cancels the lot selection prompt, the system now leaves the order line unchanged. This prevents incorrect lot information from being added accidentally, improving order accuracy for tracked products.
Original PR description
Before this commit, when loading a sale order containing an order line tracked by lot, the system prompted the user to select a lot. However, even if the user canceled the selection, the lot was still added to the order line. After this commit, the lot will no longer be set if the user cancels the selection. opw-5162487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233281
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
The printed approval request report now displays labels and field values with better spacing and more consistent text sizing. This makes approval request documents easier to read and more professional when printed or shared.
Original PR description
Steps to Reproduce: - Install approvals module. - Navigate to Approvals → My Approvals → My Requests → Print report. Issue: - The formatting of the report is not proper. Solution: - Fixed the report's QWeb template (approvals.report_aprroval_request_document). - changed col-2 to col-3 to give the labels more space and improve alignment with the field values - changed h5 to h6 for more consistent and appropriate font size throughout the document **before :** <img width="777" height="818" alt="image" src="https://github.com/user-attachments/assets/86cbaf50-191a-412b-9b8e-149442256819" /> **after :** <img width="829" height="623" alt="image" src="https://github.com/user-attachments/assets/da237a87-7a7b-45db-8347-d64e1e987469" /> Forward-Port-Of: odoo/enterprise#95609
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.
Archived bank account records are now ignored when checking whether multiple contacts share the same bank account. This prevents unnecessary warning banners on contact pages when the only matching bank account has already been archived.
Original PR description
If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records. As…
If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records. As a result, the contact page shows a banner indicating other partners use the same bank account, even though those res_partner_bank records have been archived. Steps to reproduce the issue: 1. Create a new bank account which has the same bank account number as another bank account already associated to a partner 2. Assign this new bank account to another partner 3. Archive this new bank account 4. Go to the contact page of the partner (from step 1) which has a bank account with the same bank account number as the new bank account just created 5. A banner will pop up at the top of the contact saying that this partner uses the same bank account as the partner you set on the bank account in step 2 Solution: Add a condition to the JOIN clause that checks “other.active = TRUE” to ensure that other res_partner_bank records to search for that have the same account number are active. Also add a condition to the WHERE clause that checks “this.active = TRUE” to ensure that the current res_partner_bank record doing the search is active itself. opw-4967083 Forward-Port-Of: odoo/odoo#231585
Community users can now install the Gelato integration from settings without being prompted to upgrade to Enterprise. This removes an incorrect barrier and makes the setup flow work as intended for eligible users.
Original PR description
Remove the 'Enterprise' widget from Gelato setting, which prevented community users from installing Gelato module from settings without upgrading to enterprise.
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
This update fixes a small issue when accepting Urban Piper orders in the Belgian POS certification module. It helps ensure orders from that channel are processed correctly, reducing the chance of disruption for point-of-sale operations.
Original PR description
Fix small issue in `pos_blackbox_be` module when accepting orders from Urban Piper.
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
This fixes an issue where POS session numbers could skip after a failed cash posting. Session names now advance only when the operation succeeds, keeping records easier to follow and audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/enterprise/pull/98157 opw-5180712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233784 Forward-Port-Of: odoo/odoo#233183
This fix prevents Belgian POS session names from skipping numbers when posting cash details fails. The sequence is now only used after a successful operation, helping keep session records consistent for compliance and audit purposes.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/odoo/pull/233183 opw-5180712 Forward-Port-Of: odoo/enterprise#98468 Forward-Port-Of: odoo/enterprise#98157
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