Thursday, March 19, 2026
24 changes · saas-19.1
Enhancements to existing features
This update simplifies the l10n Taiwan reports module by using the standard Odoo localization icon instead of a country flag. Adding a 'countries' key to the module's manifest enhances its organization and filtering within the Odoo platform, making it easier to find and manage.
Original PR description
Update the module icon to use the standard localization icon (l10n.png) instead of the country flag, and add the 'countries' key to the manifest to improve module categorization and filtering within the Odoo ecosystem. Task-6007589 CE PR: https://github.com/odoo/odoo/pull/252923
Resolved issues and error corrections
This update resolves a technical issue where Odoo could experience errors when communicating with Sendcloud, specifically when Sendcloud didn't return expected shipping price data. The fix prevents a system crash caused by attempting to access missing data, ensuring smoother delivery processing.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
This update fixes a bug in the Odoo Studio report editor that prevented power buttons from appearing in reports. The change ensures the Studio instance correctly defines the necessary configuration, resolving a previous issue where table menu positioning was incorrect. This improves the overall usability of the Studio report editor.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#109506 Forward-Port-Of: odoo/enterprise#109012
This update resolves an issue that prevented users from copying spreadsheets within the Odoo Enterprise system. The fix corrects a technical error that disabled the copy button, ensuring users can now seamlessly duplicate spreadsheets as needed. This restores a key functionality for managing and sharing data.
Original PR description
Fix error which disabled the copy button. Forward-Port-Of: odoo/enterprise#110700 Forward-Port-Of: odoo/enterprise#110086
This update resolves an issue where the batch view in the quality control process displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the workflow for users creating and managing quality batches. This improves user experience and reduces potential confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#109911 Forward-Port-Of: odoo/enterprise#107993
This update resolves a technical issue that prevented users from correctly editing transactions after multiple reconciliation lines were created. The fix skips a calculation step when multiple reconciled lines are present, ensuring accurate reporting and editing functionality. This improves the stability of the accounting module.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update resolves an issue where renewing a subscription while another renewal process was running would incorrectly mark the subscription as churned. The fix ensures that subscriptions are only processed when their status is actively in progress, preventing this race condition and maintaining accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update corrects a technical issue in the Account Avatax module, ensuring it properly identifies the company it's associated with. Previously, a key setting was missing, which has now been added to improve data accuracy and functionality. This ensures Account Avatax operates correctly within the Odoo Enterprise system.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves a technical issue within Odoo's Studio feature where view editing sometimes caused errors. The fix ensures that Studio correctly handles inherited views, preventing crashes and improving the stability of view creation. This change improves the overall reliability of the Studio tool.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734 Forward-Port-Of: odoo/enterprise#110835
This update resolves a minor issue preventing the correct display of a tour within the industry FSM report module. The fix ensures that the tour functionality operates as intended, improving the user experience for this specific reporting feature. This change does not impact other parts of the system.
Original PR description
task-4489657 Forward-Port-Of: odoo/enterprise#111099 Forward-Port-Of: odoo/enterprise#81823
A recent update caused the copy button within the spreadsheet functionality to become disabled. This fix resolves the issue, ensuring users can now reliably copy their spreadsheets. This improvement maintains the smooth operation of a key feature for managing data.
Original PR description
Fix error which disabled the copy button. 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#253991 Forward-Port-Of: odoo/odoo#252977
This update corrects a display issue where the batch view in the stock picking module showed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the process for users creating and managing picking batches. This improves user experience and reduces potential confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/odoo#252630 Forward-Port-Of: odoo/odoo#249581
This update fixes an issue where the formatting of PDF quotes generated with the Din5008 localization module was inconsistent when hiding product compositions. Specifically, the section background and column alignment were misaligned. The fix adds a colspan to section names to ensure proper formatting and a more professional-looking PDF quote.
Original PR description
Steps to reproduce ================== - Install website_sale,accountant,l10n_de - Select the DE company - In the accounting settings, enable the "Show Position Column in Reports" - Go to Sales - Create a new Quotation - Select a customer - Add a product - Add a section - Click on the three dots - Click on Hide Composition - Add another section - Click on the cog menu - Click on Print > PDF Quote => The background of the first section ends before the end of the line => The columns are also not aligned Solution ======== Add a colspan of 2 to the section names opw-5427590 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#252029
This update resolves an issue preventing sales users from printing quotes containing Intrastat data. Previously, access restrictions caused an error when exporting the quote to PDF. Now, users with sales permissions can successfully print quotes, ensuring accurate reporting and compliance.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales and account_intrastat - Create a user with Sales rights only - Create a product with an Intrastat Commodity Code - Connect with the created user - Create a SO with the Intrastat product - Print PDF Quote **Issue:** An access error is raised while trying to access "account.intrastat.code" field. The user needs to have an Accounting group in order to access this field. **Cause:** When printing the quote, the SO is exported in a XML to be embedded in the PDF. The field is accessed at that moment. opw-5976725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254333
A recent update to the website's job application form caused an error when users added a new file field. This fix ensures the form correctly handles the addition of this field, preventing submission failures. The issue stemmed from a change in how authorized fields are retrieved.
Original PR description
Currently an exception is generated when the user tries to submit a job application through the form. Steps to produce an error: - Install the `web_studio` and `website_hr_recruitment` modules - Add…
Currently an exception is generated when the user tries to submit a job application through the form. Steps to produce an error: - Install the `web_studio` and `website_hr_recruitment` modules - Add a new File field to the `hr.applicant` module with the studio. - Go to the website editor and add the form `Apply for a Job` and add the recently created field into the form and save it - An error will occur when submitting the form with the added field Error: `KeyError: 'manual'` This issue occurs because the `manual` key(attribute) is not included in the `authorized_fields` variable, which is generated by the `get_authorized_fields` method. After the recent refactoring introduced in commit [1], the code was changed to fetch only a limited set of attributes instead of all attributes, and the manual attribute was not added to this list. This commit resolves the above issue by including the `manual` attribute when retrieving model fields, which was not added in commit [1]. [1]: https://github.com/odoo/odoo/commit/bfae7140d3951bec93fb7f2e49018649045edd40 Sentry-7271118700 opw-5933992
This update resolves an issue where the transfer wizard tests were failing due to currency discrepancies in certain chart of accounts configurations. The fix filters accounts to avoid these currency conflicts, ensuring that all transfer tests now run successfully without impacting the core business logic.
Original PR description
Description of the issue this commit addresses: test_transfer_wizard setUpClass selected generic non-reconcile accounts. In some charts one account enforces a secondary currency causing move_1.action_post() to fail with a UserError. --- Desired behavior after this commit is merged: This commit filters accounts to those without forced account currency so setup moves always post without changing tested business flows. --- runbot-241090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254193
A test was failing due to inconsistencies in the system's clock. This fix ensures a more reliable test environment by using a fixed, deterministic datetime, guaranteeing consistent retry behavior for downloading bills. This improves the stability and accuracy of the l10n_pl_edi module.
Original PR description
The test `TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after` was failing with a stack like following, because the `now()` time was taken after the cron was executed, making the time diff sometimes shorter than the required 120s.
```
FAIL: TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after
Traceback (most recent call last):
File "/data/build/odoo/addons/l10n_pl_edi/tests/test_l10n_pl_edi.py", line 619, in test_l10n_pl_edi_download_bill_retry_after
self.assertGreaterEqual(capt.records[-1].call_at, fields.Datetime.now() + timedelta(seconds=120))
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2026, 2, 21, 4, 20, 7) not greater than or equal to datetime.datetime(2026, 2, 21, 4, 20, 8)
```
runbot-241016
Forward-Port-Of: odoo/odoo#254234This update corrects a previous issue where opening expenses from payments could cause errors when multiple expenses were linked. The change ensures the system correctly handles multiple expenses, preventing a 'singleton error' that occurred during upgrades. This improves stability and reliability when managing expenses, particularly after recent updates.
Original PR description
**Description:** In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple expenses. When opening expenses from the payment action,…
**Description:**
In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.
This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.
**To fix the issue**
the code now handles multiple expenses instead of assuming a singleton.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
return service_model.retrying(serve_func, env=self.env)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
result = func()
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
'name': self.expense_ids.name,
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```
opw-5494047
upg-3974547
[^1]: https://github.com/odoo/odoo/pull/189701
Forward-Port-Of: odoo/odoo#254167A bug was preventing portal users from submitting website forms that create tasks. This update resolves an AccessError that occurred when the portal attempted to access a specific field on the task. The fix uses a security mechanism (sudo()) to grant access to this field, ensuring smooth task creation for all users.
Original PR description
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website…
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website form that creates a task 3) Set a project on the form 4) Submit the form as a portal user ### **Error:** `AccessError: You do not have enough rights to access the field project_privacy_visibility on Task (project.task)` ### **Root Cause:** The confirmation template evaluates `task.project_privacy_visibility` in a t-if condition at [1]. since [commit](https://github.com/odoo/odoo/pull/203891/changes/17664b3f118491f954dd6a810521ce5865d51a43), project task restricts portal users to a whitelist of fields defined by [_portal_accessible_fields()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1015-L1019). Field access is then validated in [_has_field_access()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1021-L1031), which denies read access to fields not present in this whitelist. `project_privacy_visibility` is not part of the portal readable fields list. When the template tries to read it, _has_field_access() rejects the operation and raises an AccessError. [1]- https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/website_project/views/project_portal_project_task_template.xml#L13-L16 ### **Fix:** Use `sudo()` when reading `project_privacy_visibility` in the template to avoid the portal field access restriction. **opw-6010622** Forward-Port-Of: odoo/odoo#254326 Forward-Port-Of: odoo/odoo#254099
This update fixes a technical problem with how images are displayed in Odoo reports. Specifically, an error in the way image URLs were processed was corrected, ensuring images are now rendered correctly. This improves the overall presentation of reports and dashboards.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update fixes a visual issue in the table picker component of the Odoo interface. Previously, non-active cells in dark mode didn't have the correct background color. This change ensures a consistent and visually appealing experience across both light and dark themes.
Original PR description
Currently in dark mode, we don't display the right bg color for (non active) cells in table picker. This PR uses the right variable for the bg color of non active cell that is more suitable for both light and dark mode. task-6009282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252378
This update fixes an issue where the Product Screen wasn't correctly displaying the order being viewed after navigating from the Receipt Screen. The change ensures the Product Screen receives the correct order information during navigation, improving the user experience and preventing incorrect order data from being shown. This was a minor bug impacting order display.
Original PR description
When navigating via `showDefault` from the ReceiptScreen to the ProductScreen, the route and URL update correctly but `selectedOrderUuid` remains pointing to the previous (receipt) order. Since ProductScreen resolves `currentOrder` through `pos.getOrder()` (which relies on `selectedOrderUuid`), it ends up displaying the stale order instead of the one specified in the route params. Update `selectedOrderUuid` from `routeParams.orderUuid` at the start of `navigate()` so that `getOrder()` and `setScreenData` both operate on the correct order. opw-6014753 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253361
This update fixes an issue where refund orders were displaying incorrect profit margins. The change ensures margin calculations are accurately determined by directly analyzing the quantity and price of each line item in the order, regardless of whether it's a standard sale or a refund. This improves the reliability of financial reporting for refund transactions.
Original PR description
Refund orders were reporting incorrect values because the sign was derived from `is_refund`, which is not reliable. Replace with `SIGN(qty) * SIGN(price_unit) * ABS(...)` so the sign is computed directly from the line data in both `pos_order_report` and `sale.report`. opw-6017438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253023
This update resolves a problem where header border widths were incorrectly set to full widths due to a design choice in the previous version. The change ensures consistent border widths for standard headers, while still allowing full borders for specific header templates. This improves the visual consistency of website headers.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516 Forward-Port-Of: odoo/odoo#254483 Forward-Port-Of: odoo/odoo#244415