Daily updates from Odoo
Wednesday, June 3, 2026
9 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where FedEx was rejecting shipments due to the format of VAT numbers, specifically those used by countries like Switzerland. The change ensures that VAT numbers are properly sanitized to meet FedEx's requirements, preventing delivery errors and maintaining accurate data.
Original PR description
Backport of af0e834068a9ada2ad1d974c2dd6e75f876d68d9 Original PR: #109999 ----- Ticket: opw-6197750
This update fixes a bug where manual account reconciliation operations were incorrectly matched. The change reverts a previous commit that introduced this issue, ensuring accurate reconciliation processes and preventing potential data discrepancies. This improves the reliability of financial reporting.
Original PR description
This reverts commit 038f527793757c3148b775af1657c5a70a5abc66. opw-6230807
This update fixes an issue where vendor bills generated from Peppol/UBL XML files didn't automatically attach the embedded PDF. The fix ensures that the PDF is correctly extracted and included as an attachment when receiving UBL XML via email, improving the completeness of vendor bills.
Original PR description
When receiving a Peppol/UBL XML file containing an embedded PDF via an email alias, the PDF is not extracted and attached to the resulting vendor bill. Steps to reproduce: - Set up a BE Company - Configure an incoming mail server - Set up an email alias for the Vendor Bill journal - Receive a Peppol XML with embedded PDF via alias - Check the created Bill Issue: PDF has not been extracted from the xml This occurs because the received xml is set as main attachment for the record and in this case we skip extraction opw-6075250
This update addresses a performance bottleneck in Odoo's email processing, specifically related to how it searches for activity records. The previous method was slow and inefficient, leading to significant delays for regular users. This fix dramatically speeds up email operations by optimizing the record search process, resulting in faster response times.
Original PR description
Backport of v19 fix. In v17, _filter_records_for_message_operation accumulated records using the recordset |= operator, which copies and rebuilds the entire set on every iteration O(n²) total cost. On instances with many activity records not assigned to the current user, this caused response times exceeding 190 seconds for regular users while Administrator completed the same request in ~3 seconds (superuser bypasses the method entirely). Fix: Replace the recordset accumulator with a plain list and a single browse() per operation group, bringing the cost down to O(n). opw-6055334
This update addresses a slow performance issue in the Helpdesk ticket view for non-superusers. The previous method of filtering activities resulted in a significant delay (up to 2 minutes 18 seconds) due to an inefficient process. The fix replaces this with a faster method, reducing the load time to approximately 2.53 seconds, improving user experience and responsiveness.
Original PR description
Non-superusers loading a view filtered on `activity_ids` experienced severely degraded response times compared to Administrator, who bypasses the access control path entirely via an early `is_superuser()` return. Root cause: `_filter_records_for_message_operation` accumulated records using recordset |= which copies and rebuilds the entire _ids tuple on every iteration O(n²). Fix: Replace the accumulator with a plain list and a single browse() per operation group O(n). - With helpdesk.ticket list view, non-superuser, filter on `activity_ids = False` , number of tickets w/ activities not assigned to user : ~8812 : | Before | After | |:-------:|:------:| |~2m18s | ~2.53s | opw-6055334 Preceding PR -> https://github.com/odoo/odoo/pull/260147
This update resolves an issue where manually adjusted taxes on vendor bills generating COGS lines were incorrectly recalculated and reverted to the original values. The fix prevents taxes from being applied to COGS lines, ensuring accurate tax calculations for internal operations. This improves the reliability of financial reporting.
Original PR description
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This…
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them Steps to reproduce: 1. Turn on Anglo-Saxon accounting 2. Turn on automatic accounting 3. Make a FIFO product category and make the valuation automatic 4. Make a new product and set the FIFO product category on it 5. Make sure the product has a vendor tax set 6. Make a purchase order for 10 of the FIFO product category at $10 7. Create and validate the receipt for 10 8. Make a sales order for 6 of the FIFO product category at $10 9. Create and validate the delivery for 6 10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20 11. Edit the tax at the bottom of the total 12. Confirm the vendor bill 13. Notice that the tax at the bottom of the total changes 14. Reset the vendor bill 15. Remove the purchase tax from the product 16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time Cause: On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change Solution: Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids” opw-6110692
This update resolves an issue where spreadsheet formulas in the accounting module were sending incorrect data types to the server, leading to errors. Now, all company IDs are automatically converted to numbers, ensuring formulas work correctly regardless of the input format (string or number).
Original PR description
Current behavior before PR: - The `ODOO.CREDIT`, `ODOO.DEBIT`, and `ODOO.BALANCE` formulas passed `companyId.value` directly to the server without converting it to a number. - If a user passed company_id as a string (e.g., '1' from a cell), it was sent to the server as a string, causing a server error. Desired behavior after PR is merged: - `companyId` is converted using toNumber() before being passed to the getter and the server, so '1' becomes 1. - null is preserved as-is (no company filter) while any non-null value is safely cast to an integer. Task: [6240005](https://www.odoo.com/odoo/project/2328/tasks/6240005) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reverts a recent change that was disrupting the process of reconciling bank transactions with previous statements. It allows users to continue accurately matching current transactions with past records, ensuring correct financial reporting. This change addresses a workflow disruption impacting financial reconciliation.
Original PR description
This reverts commit e2a9f3bfbb8a89533146f76509bf2785c085ebea as it disrupt workflow where users needs to reconcile with a previous bank transaction Enterprise PR: https://github.com/odoo/enterprise/pull/118169 opw-6230807
This update addresses a technical bug related to how Odoo copies data using OrderedSets in Python 3.14. The fix ensures that the copy process is more stable by utilizing the dictionary's native copy method, preventing errors caused by the Python Garbage Collector. This improves the reliability of Odoo's internal data management.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy.