Wednesday, March 25, 2026
13 changes · saas-18.2
Enhancements to existing features
Invoice attachments for Serbian and Polish electronic invoicing are now saved together with the related invoice updates. This reduces the risk of records becoming inconsistent if part of the process fails.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255440 Forward-Port-Of: odoo/odoo#255262
The payment option previously shown with the legacy iDEAL branding now displays as "iDEAL / Wero" with updated Wero visual assets. This keeps checkout branding current and clearer for customers using supported payment methods.
Original PR description
Before the commit: The iDEAL payment method was using the existed legacy iDEAL logo. After the commit: - Updated the display name to "iDEAL / Wero". - Replaced the legacy iDEAL logo with the new Wero logo. - Introduced a separate "Wero" payment brand. task-5922938 Forward-Port-Of: odoo/odoo#254901 Forward-Port-Of: odoo/odoo#248506
Resolved issues and error corrections
Updates a supporting software library version so installations can use a ready-made package on common Linux systems. This reduces setup issues and keeps Odoo aligned with widely used operating system package versions.
Original PR description
This commit sets the cbor2 library's version to match more closely the Debian Bookworm/Ubuntu Jammy packaged versions and to match the ones with a prebuild wheel. Note: while the 5.4.2 already matched the one from Jammy, it didn't provided a corresponding wheel, which the 5.4.2.post1 did fix (cf. https://github.com/agronholm/cbor2/releases/tag/5.4.2.post1). runbot-238903 Forward-Port-Of: odoo/odoo#254638
Italian electronic invoices with an incorrect ENASARCO withholding reason can now still be imported when a matching withholding tax type exists. This reduces import failures and manual correction work for businesses processing supplier invoices.
Original PR description
Some invoice come in with a wrong ENASARCO withholding reason. We now broaden the search to allow taxes with the same withholding type to be used during import even if the withholding reason doesn't match. In the test, I change the Enasarco tax to reason Q to check that it gets correctly assigned. Ticket [link](https://www.odoo.com/odoo/project.task/5175587), [link](https://www.odoo.com/odoo/project.task/5933699) opw-5175587 opw-5933699 Forward-Port-Of: odoo/odoo#251734 Forward-Port-Of: odoo/odoo#236251
This fix allows users to edit taxes on loyalty reward lines once a sales order has been confirmed. It helps teams correct tax details without being blocked by a restriction that is no longer needed after confirmation.
Original PR description
Issue: --- Due to this issue, the tax on reward SOL cannot be edited. Cause: --- This is introduced in #172110 to prevent users from editing taxes on reward lines because confirming the order would recompute the tax. We can make it editable on confirmed SO as the tax wouldn't recomputed on reward lines later. opw-5918435 Forward-Port-Of: odoo/odoo#255102
Danish NemHandel invoices now use the company’s registered EAN/GLN identifier when an invoice is addressed to an individual contact linked to that company. This prevents invoices from falling back to VAT details and helps ensure electronic invoices are routed to the correct recipient.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_dk_nemhandel, and activate nemhandel. 2. Create a company partner, with a EAN/GLN as the nemhandel id. 3. Create an individual partner linked to the company partner. 4. Create an invoice with this individual partner. 5. Send the invoice with nemhandel. 6. open the xml file, and notice that the EndpointID doesn't use the EAN/GLN of the company partner. (It falls back to the VAT instead). opw-5945440 Forward-Port-Of: odoo/odoo#251783
Odoo now identifies additional assets that are loaded only when needed and prepares them before tests run. This helps avoid delays or unexpected behavior from generating those assets during the test process.
Original PR description
tl;dr: look for lazy loaded bundles and add them to the bundles' list to pregenerate before running tests to avoid generation on the fly. Forward-Port-Of: odoo/odoo#248256
This update corrects a technical issue related to how fields are populated during the creation process within Odoo. Specifically, it ensures that the correct model is used when creating certain fields, improving data accuracy and reliability. This change primarily impacts the HR and Payroll modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
This update fixes a potential issue where a user could indirectly change an employee's work email through salary contract settings. The change ensures that an employee's work_email remains consistent, regardless of whether they are linked to a user, improving data integrity. This resolves a bug identified in a previous pull request.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111243
This update automatically removes all scheduled future appraisals and associated data when an employee leaves the company. It also removes the employee from appraisal roles and archives their personal goals, ensuring data accuracy and a cleaner system after departures. This improves the HR process and reduces manual effort.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived task: 6036427
This update prevents data merge operations from silently failing due to timeouts. Instead, a warning notification is displayed, guiding users to merge smaller groups of records and reload the model upon successful completion. This enhances the reliability of the data cleaning process.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update corrects a technical issue where the system was incorrectly limiting VAT numbers submitted to FedEx, causing problems for customers using VAT numbers with longer formats (like in Switzerland). The change ensures that VAT numbers are properly transmitted to FedEx, preventing delivery errors and maintaining accurate data.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#109999
A recent bug prevented newly created approval rules in the Studio interface from being properly saved, leading to their automatic deletion. This issue arose during an upgrade from version 18.0 to 19.0 and was triggered by how the system created records for revoking approval rights. The fix ensures these records are created with a flag preventing automatic deletion.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065