Daily updates from Odoo
Friday, October 31, 2025
6 changes · saas-18.2
Resolved issues and error corrections
This fix updates website appointment and rental snippets to use the current asset-loading method. It helps keep these website features compatible with the platform and reduces the risk of display or behavior issues after upgrades.
Original PR description
See https://github.com/odoo/odoo/pull/104836 task-2963840 Forward-Port-Of: odoo/enterprise#98108 Forward-Port-Of: odoo/enterprise#35153
The approval request print report has been adjusted so labels and field values line up more clearly. This makes printed approval documents easier to read and more professional for users reviewing or sharing requests.
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
This fix prevents Belgian POS session names from skipping numbers when posting cash details fails. Session numbering now advances only after a successful operation, helping keep records complete and easier to 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/odoo/pull/233183 opw-5180712 Forward-Port-Of: odoo/enterprise#98157
This update reduces memory use when viewing incoming warehouse transfers that have many quality checks. It prevents worker crashes for large quality control workloads, making the Inventory app more reliable for affected customers.
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
Barcode scans are now ignored when a warehouse batch transfer is still being created or is not active, preventing confusing errors in the barcode app. This helps inventory users avoid crashes or misleading messages when they accidentally scan items before a batch is ready to process.
Original PR description
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which…
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors. ### Steps to reproduce: - In the settings enable "Batch Transfers" - Inventory/Operations/Transfers/Batch Transfers - Create a new batch and do not confirm it - Go to the barcode app > Batch Transfers > Clear filters - Select your draft batch - Scan anything #### > Traceback #### Other issues: The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done". ### Cause of the issue: Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179 opw-5162164 Forward-Port-Of: odoo/enterprise#97816 Forward-Port-Of: odoo/enterprise#97526
Portal users clicking “Browse Articles” from a Helpdesk help page are now taken directly to the linked Knowledge article instead of an empty knowledge home page. This restores the expected self-service support flow and helps customers find the intended help content faster.
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