Thursday, March 26, 2026
7 changes · saas-18.2
Enhancements to existing features
Invoicing users in Turkey can now verify a partner's Nilvera status during their normal invoicing workflow. This avoids failed checks caused by missing permissions and reduces the need for administrator intervention.
Original PR description
Invoicing users need to verify partner Nilvera status as part of the regular invoicing workflow, but the check was failing due to missing access rights on `l10n_tr.nilvera.alias` (create/unlink operations). Granted access to `account.group_account_invoice` to allow the check without requiring admin intervention. task-6044307 Forward-Port-Of: odoo/odoo#254609
Resolved issues and error corrections
Odoo now automatically removes unnecessary spaces from the allowed email catchall domains setting, even when it is created or edited manually. This helps ensure valid domains are recognized consistently and prevents email routing rules from silently missing a domain because of extra spacing.
Original PR description
Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`. But…
Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`. But the method is not run when the system parameter is created manually, for example through the UI, because the current conditional logic is not triggered for write and create call. This can be an issue if for example the use submits this value: "domain1.com, domain2.com,domain3.com" The comma seperated list will only be split by ',', meaning that the second element is " domain2.com" (space character in front). As such, that domain will not be used as expected, since most flows using that data will end up comparing "domain2.com" vs " domain2.com", and not considering it a match. Before this fix: Create new record in System parameters with key = "mail.catchall.domain.allowed" value = "domain1.com, domain2.com,domain3.com" -> after save, value == "domain1.com, domain2.com,domain3.com" After this fix: -> after save, value == "domain1.com,domain2.com,domain3.com" OPW-5505414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244279
This fix ensures a required Peppol BIS3 validation rule is applied through the newer invoice processing helpers. It helps keep electronic invoicing compliant in supported versions and avoids issues caused by older helper code being removed.
Original PR description
After this commit 9cb237d, the rule was added, but from 18.0 and upper the old helps has been deprecated and removed on saas~18.4. With this commit, we add the rule also to the new helpers. OPW-5881918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255870
This update ensures the external value pop-up displays numbers using the correct decimal separator based on the user's language settings. Previously, it always used a dot, which could cause confusion for users in regions that use a comma as a decimal separator. This change improves the user experience and data clarity.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#109948
This update resolves a problem where translations were failing to load correctly for the Chilean VAT reporting module. The change converts a complex list comprehension to a standard for loop, ensuring accurate translation context is used. This issue was primarily observed on Ubuntu Jammy and Debian Bookworm operating systems.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951 Forward-Port-Of: odoo/enterprise#111147
This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous successful implementation for Australia, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reporting.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711 Forward-Port-Of: odoo/enterprise#111540
This update fixes an issue where duplicating a product template automatically published it. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data accuracy and simplifies product management.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#111340