Friday, May 22, 2026
14 changes · saas-18.4
Resolved issues and error corrections
This fix prevents errors when Odoo prepares compressed PDF documents with newer PDF software components. Users can sign and download documents reliably again, including workflows that generate or mail PDFs.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/odoo#265745 Forward-Port-Of: odoo/odoo#265304
Discounts in online sales now keep the correct combined tax setup when taxes are recalculated after changing the fiscal position. This prevents duplicate or split taxes from appearing on discount lines, improving order accuracy for Canadian tax scenarios.
Original PR description
Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`.…
Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`. - Go to` Website > eCommerce > Loyalty > Discount & Loyalty.` - Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order. - Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence). - Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product. - Open the website in an incognito window > Add the product to the cart > Apply the discount code. - In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes. Issue: --- - The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST. Root cause: --- - When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST. - After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST. - In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur. - In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line. Fix: --- - Avoid splitting taxes on the discount line in the sale order. - Keep the original tax structure intact to prevent duplication after fiscal position changes. [1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156 [2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296 opw-6145674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265233 Forward-Port-Of: odoo/odoo#262147
Point of Sale now avoids automatically applying AvaTax fiscal positions when AvaTax integration is not enabled for that POS and those fiscal positions are not allowed. This prevents incorrect tax setup from being selected during checkout, reducing configuration surprises for stores.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263342
Italian electronic vendor bills from AssoSoftware files now apply pension fund taxes even when optional reference details are missing. This helps ensure vendor bill tax calculations are accurate and reduces manual corrections during invoice import.
Original PR description
### Issue before this commit: When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines. ###…
### Issue before this commit: When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it_edi_witholding 2. Change VAT number of IT company with the one in the xml 3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02 4. Import xml of the ticket in vendor bills 5. P.Fund tax is not assigned ### Cause of the issue: The issue is caused by the following line: https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the AswCassPre block without any optional child tags. ### Reason to introduce the fix: Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted. opw-6189225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264083
Stock valuation accounting entries created from purchase receipts now carry over the analytic distribution set on the purchase order line. This keeps inventory valuation reporting aligned with vendor bills and ensures costs are attributed to the right analytic accounts.
Original PR description
**Problem:** account move created by stock valuation layer does not take analytic account from PO **Steps to reproduce:** - make sure you have at least one analytic account - create a storable…
**Problem:** account move created by stock valuation layer does not take analytic account from PO **Steps to reproduce:** - make sure you have at least one analytic account - create a storable product with categ standard automated - set a positive cost - create a PO for 1 quantity - on the PO line of the product, in the analytic distribution column (might need to be unfiltered) set an analytic account - confirm PO and validate receipt - click on the valuation smart button and on the book widget of the stock valuation layer **Current behavior:** the account move lines have no analytic distribution **Expected behavior:** The account move lines should inherit the analytic account from the purchase order line like it's the case for the bill. For the analytic distribution of the Bill, the selection is : 1) take analytic distribution from PO if one 2) if not, take from distribution model if there is one 3) empty Currently for the account move lines of the svl the selection is: 1) take from distribution model if there is one 2) empty But we should use same selection as for the bill **Cause of the issue:** When setting the analytic distribution we first try to use the one from PO/SO by calling _related_analytic_distribution() https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/account/models/account_move_line.py#L1157 But since the account move lines have no purchase_line_id no analytic distribution will be returned https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/purchase/models/account_invoice.py#L540-L545 opw-6022695 Forward-Port-Of: odoo/odoo#265226 Forward-Port-Of: odoo/odoo#263236
Embedded actions linked to server actions now show the server action name directly, so labels stay current across languages. This prevents users from seeing outdated or untranslated action names when languages are added or server action names are changed.
Original PR description
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the…
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language. This has a few issues: - When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name. - When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name. The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten. To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated. Related: https://github.com/odoo/enterprise/pull/116369 Forward-Port-Of: odoo/odoo#263629 Forward-Port-Of: odoo/odoo#262981
This fix prevents website product gallery snippets from reloading unnecessarily when a mobile browser changes the visible screen size during scrolling. Customers can keep browsing the current page of items without being unexpectedly sent back to the first products.
Original PR description
Scenario: - drop product catalog snippet and save - go to the second page of product - on some mobile scroll, or just change window size Result: we are reset to the first items of the gallery. Cause: in some mobile (eg. iOS safari) scrolling up or down make the address bar appear, that makes the viewport size change. Since 18.4 refactor of website, we rerender dynamic widget at any size change, so scrolling rerender the snippet. Fix: reintroduce saas-18.2 listenSizeChange that only trigger throttled change of media breakpoint and was removed from dynamic_snippet.js in 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2. opw-6137005
Expenses paid by the company and re-invoiced to customers now use the correct quantity when creating sales order lines. This prevents the full expense total from being used as the unit price, reducing overbilling risk and improving invoice accuracy.
Original PR description
Currently, when re-invoicing an expense paid by company, the line added to the sale order will show a price unit equal to the whole expense amount. Steps to reproduce: - Create a new Expense Category with Re-Invoice Costs set to 'At cost' - Create a new Expense, set the new category, and set Paid By to 'Company' - Set Quantity to greater than 1, and Customer to Re-Invoice to any Sales Order - Confirm and Submit Journal Entry on the Expense record Issue: - On the linked Sales Order you will see the total of the expense is used as the unit price This occurs because we don't pass the quantity to the move line creation vals, which then default to 1. In turn, when the sale order line is added, the unit price will be based on the move line vals but the quantity will match the expense. opw-5883290 Forward-Port-Of: odoo/odoo#246816
Romanian eTransport submissions now show a validation message instead of failing with a system error in two edge cases. This helps users understand and correct issues when a warehouse address is outside Romania or authentication tokens are invalid.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747This update resolves an issue where removing a general note from an orderline on the preparation display would incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to accurately update existing orderlines instead of creating duplicates.
Original PR description
Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#117943 Forward-Port-Of: odoo/enterprise#113514
This update fixes an issue where the POS incorrectly applied AvaTax tax rates even when AvaTax wasn't activated in the POS settings. The system now correctly ignores AvaTax fiscal positions when a customer doesn't have a defined fiscal position, ensuring accurate tax calculations for Point of Sale transactions. This improves the reliability of the POS tax functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update improves the performance of Odoo's subscription module by adjusting how it tracks usage. The change ensures the system accurately reflects actual subscription usage, leading to faster query responses and a smoother user experience for subscription management. This optimization addresses a potential performance bottleneck.
Original PR description
runbot-163667
This update ensures that when a food delivery order is cancelled through the aggregator (Atlas), the corresponding PoS order is also correctly marked as cancelled in the system. Previously, PoS orders remained in an active state, leading to inaccurate order tracking. This fix improves order visibility and accuracy for both staff and customers.
Original PR description
pos*: pos_urban_piper, pos_enterprise When a food delivery order is cancelled from the aggregator side, the PoS order remains active on the frontend instead of reflecting the cancelled state. Steps to reproduce: - Configure UrbanPiper with Atlas - Place an order via Atlas - Open the order from the notification bar - Cancel the order from Atlas Issues: - Cancelled orders continue to appear in `Draft` - Accepted/preparation orders are not cancelled on the preparation display Fix: - Synchronise the PoS order state with the delivery state on cancellation - Update preparation display orders when delivery orders are cancelled Task-6217704 Forward-Port-Of: odoo/enterprise#117942 Forward-Port-Of: odoo/enterprise#117374
This update resolves an issue where signed PDF documents lost their original bookmarks and links. The fix ensures that signed documents remain fully navigable and preserve the original document structure and integrity, improving user experience and data consistency.
Original PR description
Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links. 2. Sign the document and download the signed PDF. 3. Open the downloaded file and check the bookmarks and links. Issue: When a signed document was downloaded, the original PDF bookmarks And the links were not working. This broke structured navigation and affected document integrity. Fix: The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing. Impact: - Signed documents remain navigable and consistent with the original PDF. - Preserves document structure and integrity. Task- 4915124 Forward-Port-Of: odoo/enterprise#117881 Forward-Port-Of: odoo/enterprise#108684