Thursday, March 26, 2026
19 changes · saas-18.3
Resolved issues and error corrections
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 solution 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 resolves a technical issue impacting the export functionality of Web Studio. Previously, exported properties were incorrectly formatted, now they are correctly converted to XML records, ensuring accurate data exports for reporting and other uses. This improves the reliability of Web Studio's export capabilities.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4
This update ensures that the 'mail.catchall.domain.allowed' system parameter is properly sanitized when created through the Odoo UI. Previously, a formatting issue caused incorrect domain comparisons, potentially preventing email notifications from being delivered. This fix resolves this issue, guaranteeing accurate domain validation and reliable email functionality.
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 update allows invoicing users to check the Nilvera status of their partners, a key step in the invoicing process. Previously, this check was failing due to access restrictions. Granting access to the `account.group_account_invoice` group now resolves this issue without requiring 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
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance records. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance or working during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#110991This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing accidental product listings. This improves data consistency 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
This update resolves an issue where users would encounter an error when attempting to save a report with an empty XML format. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data loss.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255316
This update resolves an issue where saving a report with an empty XML format in Web Studio would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience. This change improves stability and usability for report creation.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#88613
This update fixes an issue where the SEPA payment file version was incorrectly displayed as empty in the user interface. The fix ensures the correct 'PAIN 09' version is generated, aligning with Odoo's financial reporting standards. This improves the accuracy of payment file generation.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update automatically checks out employees from attendance when they are archived. Previously, archived employees remained checked in, which created inconsistencies. This change ensures accurate attendance records and simplifies the process for administrators.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255845 Forward-Port-Of: odoo/odoo#255524
This update fixes a previous issue where tax names were incorrectly displayed in English for Spanish users. Now, all tax names are accurately shown in Spanish, improving the user experience and ensuring compliance with local regulations. This change was approved through a legal agreement.
Original PR description
It was a previous dev in which the fw-port failed. Here is the old [PR](https://github.com/odoo/odoo/pull/238857) The tax names were displayed in English, and it's confusing for the Spanish users. Now, the taxes are displayed in spanish task-6041023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255074
This update resolves an issue where taxes on reward lines within sales orders couldn't be edited after the order was confirmed. Previously, confirming the order would recompute taxes, preventing edits. Now, taxes can be edited on confirmed reward sales orders without impacting the final total. This improves flexibility for users managing reward programs.
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#255644 Forward-Port-Of: odoo/odoo#255102
This update fixes a display issue in the external value pop-up, ensuring it uses the user's preferred decimal separator (like a comma or dot) based on their language settings. Previously, the pop-up always displayed numbers with a dot, regardless of the user's locale. 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#111997 Forward-Port-Of: odoo/enterprise#109948
This update corrects a technical issue where the system was incorrectly limiting VAT numbers to 18 characters, causing problems with FedEx integration. The fix ensures that VAT numbers, including those used in countries like Switzerland with longer formats, are properly transmitted to FedEx, preventing delivery errors. This improves the reliability of shipments.
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#111864 Forward-Port-Of: odoo/enterprise#109999
This update resolves an issue where filters remained visible on the shop page in mobile view, even when the 'hide' option was selected. The fix ensures that filters are only displayed when a visibility option other than 'hide' is chosen, improving the mobile user experience. This change enhances usability and consistency across devices.
Original PR description
Steps to reproduce: 1) Go to the shop page 2) Open the editor and select the 'hide' option for filters 3) Switch to mobile view and click on the 'Filters' button Issue: - Filters are still displayed in mobile view even when the 'hide' option is selected in the editor. Cause: - The attribute filters template is always rendered in mobile view without checking the selected visibility option. Fix: - Add a condition to the `t-call` of the filters template so it is only rendered when an option other than 'hide' is selected. opw-5982147
This update resolves an issue where the customer rating form displayed a duplicate 'Comment' field, causing confusion for users. The fix makes the redundant 'publisher_comment' field invisible, streamlining the form and improving the user experience. This ensures consistent and accurate customer feedback reporting.
Original PR description
**Steps to reproduce:** - Enable the customer rating from project's setting. - Go to project > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in project's customer rating **Task-id: 5359052**
This update resolves a visual issue in the Customer Ratings reporting module where a duplicate 'Comment' field was displayed. The fix removes the redundant 'publisher_comment' field, streamlining the form and ensuring a cleaner user experience. This improves data clarity and consistency for users.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052**
A bug was fixed that caused the coupon form to disappear when a pricelist with an 'E-commerce Promotional Code' was selected. This change was initially implemented for a previous feature but is no longer needed. The fix ensures the coupon form remains visible, allowing users to apply promotional codes correctly.
Original PR description
Issue: --- If the current pricelist has `E-commerce Promotional Code` set, the coupon form is hidden. Steps to reproduce: --- 1- Create a pricelist and set `E-commerce Promotional Code`. 2- Navigate to the cart in website. 3- Enter pricelist code in the coupon form. Result: Once the code is entered, pricelist is changed and the coupon form is hidden. Cause: --- This is done intentionally on #23713. However, it seems it's not relevant anymore. Fix: --- We can remove `force_coupon` condition from `reduction_code` template. However `force_coupon `is also used inside xpath expression in `reduction_coupon_code` template. In order not to break stable we can keep `t-set="force_coupon"` inside the `reduction_code` template, and remove it on master. opw-5977474 Forward-Port-Of: odoo/odoo#252518
This update optimizes the testing process by pre-generating the `bus.websocket_worker_assets` bundle. Previously, this bundle was rebuilt repeatedly during tests, causing delays. This change significantly speeds up test execution times, improving overall development efficiency.
Original PR description
This commit sets the `bus.websocket_worker_assets` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +900 times with a db "all"). Forward-Port-Of: odoo/odoo#255843