Odoo Changelog — 2026-06-03

Wednesday, June 3, 2026

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[REV] account: avoid past manual operation from being matched

Enterprise17.0accountMEDIUM

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

#account reconciliation#finance#bug fix

[FIX] account_edi_ubl_cii: pdf not extracted from xml

PR #260629

Core17.0account_edi_ubl_ciiMEDIUM

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

#UBL#Peppol#EDI#PDF#Vendor Bills

[PERF] mail: fix O(n²) accumulation in access filter

PR #267756

Core17.0mailMEDIUM

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

#performance#email#optimization

[PERF] mail: fix O(n²) accumulation in access filter

PR #267939

Core17.0mailMEDIUM

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

#performance#helpdesk#user experience

[FIX] account: prevent taxes on COGS lines

PR #265352

Core17.0accountMEDIUM

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…

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

#tax#COGS#vendor bill

[REV] account: avoid past manual operation from being matched

PR #266057

Core17.0accountMEDIUM

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

#bank reconciliation#finance#accounting

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

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

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

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 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