Thursday, March 26, 2026
22 changes · saas-18.4
Resolved issues and error corrections
Users editing report sources can now save a report even if the XML source is empty, without encountering a technical error. This prevents interruptions in Studio report editing and keeps the save flow stable when no XML content is present.
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
When a partner's country is changed, Odoo now updates the available identification type to match that country. This prevents records from being saved with mismatched country and local ID information, improving data consistency for Latin American localizations.
Original PR description
**PROBLEM** PR: https://github.com/odoo/odoo/pull/179078 Removed _onchange_country_id() which was used to set the identification type according to the country of the partner. This PR reintroduce it, so id type and country remains consistent. **STEP TO REPRODUCE** 1. install l10n_ar and l10n_co. 2. create a new partner. 3. set its country to Argentina, and select an argentinian id type. 4. set the country to Colombia and save. You end up with a partner from Colombia, with a id type that is used for Argentinian partners which shouldn't be possible. opw-5801824 Forward-Port-Of: odoo/odoo#248585
The test setup now prepares the bus websocket asset package in advance instead of rebuilding it repeatedly during test runs. This reduces unnecessary work in automated testing and helps keep validation faster and more reliable without changing end-user behavior.
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
Point of Sale receipts no longer show the company information twice. This keeps printed and digital receipts clearer and more professional for customers.
Original PR description
Before this commit, the receipt was showing the company information twice. It happened after the commit https://github.com/odoo/odoo/commit/dca40d16481ba504d608cc65d82e7821e01c5932. opw-6053013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255368
Odoo now cleans up the allowed catchall email domain list even when it is entered manually in system settings. This prevents domains with accidental spaces from being ignored, helping incoming email routing behave as expected.
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
Users can now replace an uploaded file in the link popover without first clearing the existing generated URL. This makes editing links smoother and avoids extra manual steps when the wrong file was uploaded or a file needs to be updated.
Original PR description
Specification: - When a user uploads a file in the link popover, user can not re-upload another file without manually removing previous URL. <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/9e67535a-22a1-4d41-808d-a91d07593251" /> <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/92a33d8c-a325-4979-9956-42e81b369bd7" /> After this commit: - This commit allows user to re-upload a file without removing previously generated URL first. - TL;DR : upload button won't disappear. task-5470111 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an automated restaurant point-of-sale test that could fail because it moved too quickly while an order was still synchronizing. It helps keep quality checks reliable without changing the customer-facing restaurant workflow.
Original PR description
The tour `test_preset_timing_restaurant` from the test suite was failing because the steps were executed too quickly. When creating a new order, the preset timing popup is opened, which triggers a synchronization of the order. At that moment, the order has no order lines, and the synchronization takes some time to complete. During this delay, the tour adds a new order line while the sync is still in progress. As a result, when the `sync_from_ui` response returns, the frontend data is updated with the synchronized order (which still has no order lines), overriding the order line that was just added. runbot error: 234567 --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/234567 Forward-Port-Of: odoo/odoo#254190
Sales teams can now adjust taxes on loyalty reward lines after a sales order has been confirmed. This fixes a restriction that blocked legitimate tax corrections, while avoiding unwanted recalculation of reward line taxes later.
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
When an employee is archived, the system now checks whether they are still clocked in and automatically records a checkout at the current time. This prevents open attendance records from remaining unresolved and keeps attendance data accurate.
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
The live chat test setup now prepares a required web asset bundle in advance instead of rebuilding it repeatedly during test runs. This reduces unnecessary processing during automated testing and helps keep validation runs more efficient without changing the customer-facing live chat experience.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#256149 Forward-Port-Of: odoo/odoo#255847
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a €1,000 turnover threshold, considering both invoices and credit notes. This ensures more reliable financial reporting.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111737 Forward-Port-Of: odoo/enterprise#101333
This update fixes a potential issue where a user could indirectly change an employee's work email through salary contract updates. Previously, linking an employee to a user allowed for this unintended modification. Now, the system ensures the work_email remains consistent, regardless of whether the employee is linked to a user, improving data integrity.
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#111955 Forward-Port-Of: odoo/enterprise#111243
This update corrects a technical error preventing Point of Sale sessions from closing properly. The fix involves renaming a method within the 'l10n_de_pos_cert' module to ensure correct cash move formatting, resolving a previously reported issue. This ensures seamless POS operation.
Original PR description
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS…
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS interface, open the menu (☰ icon) in the top-right corner. 4. Navigate to the Cash In/Out functionality. 5. Perform a cash operation: - Select either Cash In or Cash Out - Choose a Category Reason - Select a Type Reason - Confirm the operation 6. Attempt to close the POS session. **Issue:** In version saas-18.2, an error occurs when closing the POS session because the name of the cash move (in the Cash Register) is incorrect. It should be formatted as: `Hauptmarkt/00006-out-category reason-reason` However, it is currently generated as: `Hauptmarkt/00006-out-reason` This happens because the method `"_prepare_try_cash_in_out_payload"` in "l10n_de_pos_cert" is not called due to an incorrect method name. **Solution:** The issue is resolved by renaming the method to the correct name `"_prepareTryCashInOutPayload"`. This ensures the proper method is invoked, generates the correct cash move name, and allows the POS session to close successfully. opw-6059143 Forward-Port-Of: odoo/enterprise#111597
This update resolves an issue where saving a report with an empty XML format in the Web Studio tool 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 ensures that when an employee leaves, any scheduled future appraisals are automatically cancelled and archived. Additionally, the employee is removed from appraisal roles, and their personal goals are archived, streamlining the process and preventing outdated appraisals from being created.
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 Forward-Port-Of: odoo/enterprise#111589
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. 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 unintended product listings. This improves data consistency and reduces manual intervention.
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 fixes an issue where SEPA payment files were incorrectly generating with an outdated version (PAIN 09) even when the underlying data was correct. The fix ensures the correct PAIN version is used, improving the accuracy of payment file generation. This prevents potential errors with bank transfers.
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 resolves a minor issue where the helpdesk tour occasionally failed due to the tour attempting to click a button before the kanban view was fully loaded. By ensuring the kanban view is fully rendered before the tour attempts to interact with it, this fix improves the overall stability and reliability of the tour experience.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081** Forward-Port-Of: odoo/enterprise#110333
This update fixes a display issue in the external value pop-up, ensuring it uses the user's locale (language) to correctly format numbers with the appropriate decimal separator (like a comma instead of a dot). This improves the user experience by presenting financial data in a format that aligns with their preferred regional settings.
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 number lengths when integrating with FedEx. The change ensures that VAT numbers, including those with longer formats like in Switzerland, are properly transmitted to FedEx, preventing delivery errors. This improves the reliability of shipments using FedEx.
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 tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from the hourly wage and multiplier, mirroring a previous solution for Australia, ensuring accurate overtime pay is displayed. This improves the precision of reported payroll amounts.
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#111740 Forward-Port-Of: odoo/enterprise#111540