Tuesday, March 31, 2026
27 changes · saas-19.2
Resolved issues and error corrections
This update resolves an inconsistency in the tax report when creating vendor bills with mixed vehicle and non-vehicle expense lines. The fix allows for accurate reporting by relaxing a strict matching rule that previously flagged these lines as inconsistent. This ensures all tax calculations are correct.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document handling system, ensuring that renamed documents can now be successfully opened. This improves the reliability of the documents feature for all users.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110315 Forward-Port-Of: odoo/enterprise#105602
This update fixes a problem where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The change skips PDF extraction when raw data is missing, ensuring that PDF files are consistently generated and preventing errors.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update corrects a technical issue related to how the suspense line is calculated in the account accounting module. The change ensures the suspense line is always a valid object, preventing a validation error. This resolves a potential instability in the system.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update resolves a bug where commission calculations were incorrectly defaulting to 0% when the target completion was set to 0%. The fix ensures that commissions are accurately calculated when the target amount is zero, addressing a previous inconsistency in the system.
Original PR description
Before this commit, when target completion was 0% and the commission was equal to X (where X is not null), the commission could not be equal to X. It would be equal to 0. It was working with target amount equal to 0. Forward-Port-Of: odoo/enterprise#112337
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 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#112462
Forward-Port-Of: odoo/enterprise#110991This update resolves a technical issue that caused the Invoicing dashboard to display a traceback error for certain companies. The fix ensures that the system gracefully handles companies without Stripe configured, preventing errors and maintaining dashboard functionality. This improves the user experience for all users.
Original PR description
Steps to reproduce: 1. Install `l10n_ar`. 2. Switch to an AR company. 3. Open the Invoicing dashboard. Issue: Opening the dashboard raises a traceback: `ValueError: Expected singleton: res.currency()` Cause: When Stripe is not configured on the company, `stripe_currency_id` is empty, leading to an invalid currency recordset during formatting. Fix: Fallback to the company currency when `stripe_currency_id` is not set. opw-6049551
This update resolves a technical issue related to the EU IoT scale certification driver. Following a recent fix to the scale driver, a corresponding checksum update is required to ensure data integrity and compliance. This change is a routine maintenance task.
Original PR description
As we fixed the scale driver, we need to update the checksum. see odoo/odoo#256816
This update corrects a technical error in the E-Commerce Reporting module (l10n_eg_iot) where a controller was referencing outdated code from a previous Odoo version. This fix ensures the reporting functionality is working correctly and prevents potential disruptions to business processes. It's a routine maintenance update.
Original PR description
`iot_box_setup` override is still calling the previous method names, mistakenly fw ported from 19. This commit fixes it. Forward-Port-Of: odoo/enterprise#112451
This update resolves a technical issue within the Bank Reconciliation widget that could cause errors when deleting counterpart lines in bank transactions. The fix ensures the system correctly handles data, preventing unexpected errors and improving the reliability of bank reconciliation processes. This change was triggered by internal testing and development.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112546 Forward-Port-Of: odoo/enterprise#112175
This update corrects a previous inconsistency in how sections are handled within Odoo's sale order system. Previously, the behavior of optional sections and hidden sections differed between sale orders and their templates. This change ensures that these settings are consistently applied across all sales order types, improving usability and reducing potential errors.
Original PR description
This commit fixes inconsistencies between section behavior in sale orders and sale order templates. In sale orders: * A section cannot be marked as optional if it is hidden, and vice versa. * Moving an optional subsection into a hidden section resets its optional state. * Enabling 'hide composition' on a section resets the optional state of its subsections. These rules were not consistently enforced in sale order templates, leading to mismatched behavior. This commit aligns template logic with sale order behavior to ensure consistency across both. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256567
This update fixes an issue where Italy's chart of accounts was defaulting to incorrect expense and revenue accounts. The change explicitly sets the correct Italian deferred accounts (`190200` and `270200`) within the chart template, ensuring accurate financial reporting for Italian businesses.
Original PR description
Italy's chart template did not explicitly define deferred expense and revenue accounts, so deferred accounts fell back to the first `asset_current` and `liability_current` accounts in the chart. That could assign incorrect defaults such as `140100` and `220100`. This patch sets the intended Italian deferred accounts to `190200` and `270200` directly in the template to ensure correct configuration during chart loading. task-6076711 Forward-Port-Of: odoo/odoo#256623
This update ensures that when creating new analytic items from the gross margin smart button, the correct analytic account is automatically selected by default. Previously, new items weren't linked to an account, requiring manual setup. This change streamlines the process and improves data accuracy for analytic reporting.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256426 Forward-Port-Of: odoo/odoo#255726
This update resolves a technical glitch that was causing a test tour to fail during product catalog setup. The fix ensures the correct section ID is always used, preventing errors and improving the reliability of the product selection process. This ensures a smoother experience for users adding products to their orders.
Original PR description
Cause: The `selectedSectionId` was not yet updated in the environment when the product was added, resulting in a `None` value being passed to `_update_order_line_info`. Fix: Use `this.env.selectedSectionId` when available, and fall back to `this.env.searchModel.selectedSection.sectionId` only if it is undefined or null. runbot-241960 Forward-Port-Of: odoo/odoo#254374
This update fixes a technical issue where the removal of certain tags from Odoo's core reporting system wasn't reflected in the import file. This ensures that the import process correctly reflects the latest changes to Odoo's reporting functionality. It's a minor update focused on data consistency.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116
This update resolves an issue where default account settings for Swiss businesses in Odoo were incorrectly configured. The change sets clean, accurate default values, ensuring proper accounting and reporting for Swiss users. This improves the reliability and accuracy of financial data.
Original PR description
[IMP] l10n_ch: Set default accounts in Switzerland Some defaults accounts in Switzerland were misconfigured, this commit set clean values by default task-6043978 Forward-Port-Of: odoo/odoo#255350
This update addresses a sporadic validation error that occasionally occurred when managing users within the settings. The issue stemmed from a conflict in how employee data was linked, preventing users from being added correctly. This fix ensures a stable and reliable user management experience.
Original PR description
## Short functional explanation of the error When in settings, we click on Manage users, we sometimes get a validation error. ## Reproduction Steps 1. Go to settings. 2. Click on Manage Users. ###…
## Short functional explanation of the error When in settings, we click on Manage users, we sometimes get a validation error. ## Reproduction Steps 1. Go to settings. 2. Click on Manage Users. ### Expected behavior The list of users is displayed. ### Unexpected behavior Sometimes (around 20% of the time), we get the error: ``` Validation Error The operation cannot be completed: A user cannot be linked to multiple employees in the same company. ``` ## Origin of the issue This validation error is triggered due to a psycopg2 constraint error. Indeed, it occurs because the code tries to create an employee for the current user, when an employee for this user already exists: https://github.com/odoo/odoo/blob/35da8c4d8e86a752cc76d275463a752039465984/addons/pos_hr/models/pos_config.py#L27-L30 In our case, the `group_users` only contains the admin user. This user has an existing corresponding employee in the field `employee_ids`, but not in `employee_id`. __ opw-6066533 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a critical error that occurred when users attempted to create scrap orders without specifying a scrap location. The issue stemmed from accessing an empty dictionary after a scrap location was deleted, leading to a traceback. This fix ensures the scrap order creation process remains stable and reliable.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252192
This update strengthens a key test for Odoo's editing functionality. The test now explicitly verifies the correct behavior of the right-click context menu, making it less reliant on timing. This ensures more reliable test results and improves the overall stability of the editing experience.
Original PR description
This PR is a follow up of https://github.com/odoo/odoo/pull/256063 Use `expect.waitForSteps()` in the right-click editing test to assert the message context-menu flow more explicitly instead of relying only on `animationFrame()`. The test now verifies that: - `onContextMenu()` is triggered - `showRightClickMessageActions()` is not triggered while editing This makes the test less timing-dependent. Forward-Port-Of: odoo/odoo#256670
This update fixes an issue where custom invoice headers provided by the `l10n_cl` module were not appearing in Odoo 19.2. The change restores the correct display of these custom headers, ensuring invoices generated for the Chilean market accurately reflect the required formatting. This resolves a prior display problem.
Original PR description
### Issue: In 19.2, the custom header defined by `l10n_cl` was not displayed on invoices The standard layout was used instead ### Cause: This change: https://github.com/odoo/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df modified the `t-call` behavior to ignore `t-set` inside the call Since the `o` variable is defined within the `t-call` in the invoice report: https://github.com/odoo/odoo/blob/a08e84e84aa26e86a291ef0de5bdd4ac20f6274e/addons/account/views/report_invoice.xml#L110-L115 the custom parameter header was ignored ### Steps to reproduce: - Install `l10n_cl` and switch to the CL company - Create and confirm an invoice - Open the preview ### Before the fix: The default header is used ### After the fix: The custom header are correctly applied (as in 19.1) opw-6057122
This update resolves an issue in Odoo 19.2 where custom header and footer designs from the `l10n_ar` localization module were not displayed on invoices. The fix corrects a technical detail related to how Odoo reports handle parameters, ensuring the correct localized invoice layouts are used as in previous versions.
Original PR description
### Issue: In 19.2, the custom header and footer defined by `l10n_ar` were not displayed on invoices The standard layout was used instead ### Cause: This change: https://github.com/odoo/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df modified the `t-call` behavior to ignore `t-set` inside the call Since the `o` variable is defined within the `t-call` in the invoice report: https://github.com/odoo/odoo/blob/a08e84e84aa26e86a291ef0de5bdd4ac20f6274e/addons/account/views/report_invoice.xml#L110-L115 the custom parameters (header and footer) were ignored ### Steps to reproduce: - Install `l10n_ar` and switch to the AR company - Create an invoice - Open the preview ### Before the fix: The default header and footer are used ### After the fix: The custom header and footer are correctly applied (as in 19.1) ### Fix: This PR also fix the delivery guide document opw-6046454
This update resolves an issue where right-clicking while editing a message in the Odoo messaging system incorrectly opened a custom context menu instead of the standard browser menu. Now, right-clicking during message editing correctly displays the browser's default context menu, improving the user experience.
Original PR description
Before this commit, right-clicking while editing a message opened the message context menu instead of the browser's default menu. After this commit, right-clicking while editing a message opens the browser's default context menu, and the message context menu is no longer triggered. task-6065753 Forward-Port-Of: odoo/odoo#256063
This update resolves a technical issue within the IoT drivers module that prevented proper communication with serial devices. The change ensures the necessary connection object is passed to a key function, restoring functionality and stability. This fix is important for ensuring reliable data collection from connected devices.
Original PR description
The `_get_raw_response` method was refactored to be static, but a fw port broke its use by missing to provide the serial connection object as parameter.
This update corrects a visual inconsistency in the 'muted' call action within discuss calls. The icon's background color was previously pink instead of red, which has now been fixed to match the standard 'disconnect' button. Maintaining the `.active` class ensures consistent styling across discuss actions.
Original PR description
Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red. The color should be the same as the one from…
Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red. The color should be the same as the one from "disconnect", but the difference comes from `btn-danger` with or without `.active` that has different shade of red for background: the `.active` version is lighter like in the mute button when active. `.active` classname is preferred to keep so that the visual is consistent for most discuss actions, including the ones without success / danger which a majority of these buttons have. However, the buttons with danger / success style are intended to preserve their color unchanged as the `.active` aspect is meant to tell whether the button is active or not and the slight change of color shade is not desirable in the context of discuss action list. This commit uses the same background color for danger / success / primary inline button. Other styles line dropdown and inline buttons without background had already the same colors, so this commit fixes the only case that was missing. Task-5436990 Before / After <img width="283" height="38" alt="Screenshot 2026-03-13 at 15 21 22" src="https://github.com/user-attachments/assets/3ebba48c-5b22-43e9-a915-e18a5531e660" /> <img width="270" height="41" alt="Screenshot 2026-03-13 at 15 21 45" src="https://github.com/user-attachments/assets/586d05a4-2a6c-48e0-89c6-bffa85a86e59" /> Forward-Port-Of: odoo/odoo#255282 Forward-Port-Of: odoo/odoo#253923
This update corrects a problem where newly added billing addresses were incorrectly displayed in both the delivery and billing sections of the customer portal. The fix removes a technical setting that caused the address type to be misconfigured, ensuring addresses are now correctly associated with billing information.
Original PR description
Versions -------- - 19.0+ Steps ----- - Log in on the portal - Go to "My Account" - Go to "Addresses" - In the billing section uncheck "Same as delivery address" - In the billing section click "Add…
Versions -------- - 19.0+ Steps ----- - Log in on the portal - Go to "My Account" - Go to "Addresses" - In the billing section uncheck "Same as delivery address" - In the billing section click "Add Address" - Fill in address details - Click "Save Address" Issue ----- The newly added address is visible in both the delivery and billing sections, and in the backend the address has type "other" instead of "invoice". Cause ----- This happens because the "Add Address" url in the billing section contains the parameter `use_delivery_as_billing=True`, which supersedes the parameter `address_type=billing`, creating an address with type "other". This is because the "Add Address" url in the billing section is not dynamically updated when the "Same as delivery address" toggle is toggled like with the url in the delivery section. Solution -------- The `use_delivery_as_billing` is completely removed from the url in the billing section, because the button only appears when the toggle is unchecked (i.e. when `use_delivery_as_billing=false`). And by not sending the parameter, it defaults to false in the backend. opw-5880430 Forward-Port-Of: odoo/odoo#256326
This update resolves an issue where the system incorrectly flagged duplicate account codes, even when accounts were archived. Specifically, it ensures that archived accounts are now checked during the creation of 'unaffected earnings' accounts, preventing validation errors and ensuring smooth upgrades, particularly with the `l10n_sa` module.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
Features or functions removed from Odoo
This update removes a confusing tooltip from the account tax scope field. The tooltip provided unnecessary detail, which was deemed not needed at this time. This simplifies the user experience and streamlines the account tax configuration.
Original PR description
Remove the misleading tooltip entirely. No need to have more details on that field right now. Task [link](https://www.odoo.com/odoo/project.task/5946889) task-5946889 Forward-Port-Of: odoo/odoo#256573