Wednesday, March 18, 2026
23 changes · saas-18.3
Resolved issues and error corrections
This update fixes a technical issue in the Odoo Enterprise software related to demo certificates used for Peru's electronic invoicing (PE) requirements. The certificate's lifespan was extended by ten years to align with current regulations, ensuring accurate reporting within the system. This change ensures continued compliance and proper functionality for users utilizing the l10n_pe_edi module.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058 Forward-Port-Of: odoo/enterprise#110719
This update resolves an issue that prevented demo data from loading correctly when errors occurred during the process. By preventing errors related to missing record IDs, the system is now more robust during demo data installation and loading, ensuring a smoother user experience. This improves the reliability of initial module setup.
Original PR description
``` * = {appointment_account_payment, appointment_hr_recruitment, mrp_workorder, quality_mrp_workorder, quality_mrp_workorder_worksheet} ``` Currently, an error may occur if a referenced record ID…
```
* = {appointment_account_payment, appointment_hr_recruitment,
mrp_workorder, quality_mrp_workorder, quality_mrp_workorder_worksheet}
```
Currently, an error may occur if a referenced record ID is not found during XML data loading. This can happen in various scenarios, including:
- While loading demo data during module installation.
- When an exception interrupts demo data loading, it prevents remaining data from being processed.
- When demo data is being loaded while the module is simultaneously being uninstalled in another session.
**Steps to Reproduce:**
- Install all the modules without demo data.
- Go to settings and manually load the demo data.
- If a user error occurs during this process, the demo data load will fail and raise an error.
**Error:**
`Could not eval([(4, ref('mrp.product_product_computer_desk'))]) for product_ids in {"lang":null}`
This commit applies `raise_if_not_found=False` to XML references in `eval`, preventing errors when the referenced external ids are missing.
Related-community-PR: https://github.com/odoo/odoo/pull/212295
Sentry - 3935871751This update resolves a potential error that occurred when loading demo data in the pos_loyalty module. The change prevents errors if referenced records aren't found during the loading process, ensuring demo data can be loaded consistently even with interruptions or concurrent uninstallations.
Original PR description
Currently, an error may occur if a referenced record ID is not found during XML data loading. This can happen in various scenarios, including:
- While loading demo data during module installation.
- When an exception interrupts demo data loading, it prevents remaining data from being processed.
- When demo data is being loaded while the module is simultaneously being uninstalled in another session.
**Steps to Reproduce:**
- Install all the modules without demo data.
- Go to settings and manually load the demo data.
- If a user error occurs during this process, the demo data load will fail and raise an error.
**Error:**
`Could not eval([(4, ref('mrp.product_product_computer_desk'))]) for product_ids in {"lang":null}`
This commit applies `raise_if_not_found=False` to XML references in `eval`, preventing errors when the referenced external ids are missing.
Related-enterprise-PR: https://github.com/odoo/enterprise/pull/86681
Sentry - 3935871751This update resolves an issue where validating a delivery record would cause an error when the associated sale order lacked order lines. The fix automatically assigns a default sequence value of zero, ensuring deliveries can be validated correctly even without existing order lines. This improves the reliability of the delivery process.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239030
This update resolves a technical issue that prevented users from running the automated download of vendor invoices from the Polish KSeF system when rate limits were exceeded. The fix ensures that error messages are handled correctly, preventing a common traceback error and allowing the scheduled action to continue functioning properly.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Run scheduled action "Polish eInvoice: Download vendor bills from KSeF" 3. If the customer gets 429 Too Many Requests => A traceback error is raised as message isn't an attribute in KSeFRateLimitError object `AttributeError: 'KSeFRateLimitError' object has no attribute 'message'` This happens because `KSeFRateLimitError` does not define a `message` attribute. The message is only passed to the base Exception and stored in `args`. After this commit: Use `str(e)` to properly retrieve the exception message and avoid the AttributeError. opw-6009380 Forward-Port-Of: odoo/odoo#253549
This update resolves an issue where users creating freelance employees would receive an error message about missing SDWorx codes. The fix ensures that the system correctly skips this validation check for freelancers, streamlining the export process and preventing unnecessary errors.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update resolves a test failure caused by overly sensitive checks for loading indicators (fa-spin). The trigger has been removed, ensuring tests run smoothly even with minor delays in the system. This improves the reliability of our testing process.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025) Forward-Port-Of: odoo/enterprise#87281
This update ensures that the system correctly handles file uploads, specifically by verifying the MIME type passed to the 'File' constructor. This change aligns with Chrome's latest standards and prevents compatibility issues with older browser versions, ensuring smoother file operations.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/odoo#254154 Forward-Port-Of: odoo/odoo#253631
This update ensures that new files created within the Odoo Enterprise system correctly identify their file types (mimetypes). This fix addresses a compatibility issue with older versions of Chrome, aligning with current web standards and preventing potential display or functionality problems.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/enterprise#110812 Forward-Port-Of: odoo/enterprise#110496
This update ensures that payments received from external providers are always fully reconciled – either completely paid or not paid at all. Previously, partial reconciliation was allowed, which created an inaccurate record of transactions. This change improves the accuracy of financial reporting.
Original PR description
When we receive a payment from a provider, we allow partial reconciliations to be done on this move, but we shouldn't. Payments coming from providers are always either fully paid, or not paid at all. task-5893189
A test was failing due to inconsistencies in the system's clock. This update ensures the test accurately measures the time it takes for a bill retry process, guaranteeing reliable test results and preventing potential delays in automated bill downloads. This improves the stability 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 resolves an issue where changing the copyright footer background color would cause a CSS error when the footer had no background color. The fix adds a fallback value to ensure the copyright color displays correctly regardless of the footer's background setting, improving website appearance consistency.
Original PR description
Before this commit, a css error would happen when the user tried to change the copyright background color if the footer had no background color.
This was due to $-footer-color not having a fallback value when neither o-color('footer-custom') nor o-color('footer') was defined.
This commit adds a fallback value to fix the issue.
task-5452457
Forward-Port-Of: odoo/odoo#248283This update fixes a display problem with the mega menu on mobile devices. Previously, when the mega menu was set to 'Narrow,' it would sometimes take up too much space. This change ensures the mega menu's width is correctly controlled, preventing oversized displays and maintaining a consistent user experience.
Original PR description
The property "max-width" of the mega menu in mobile view was set with the class o_mega_menu_is_offcanvas of its ancestor. However, when the user set the mega menu template size to "Narrow", new CSS rules were added to change the mega menu size based on the screen size. The first rule was overridden, resulting in the mega menu being larger than the mobile navbar width. This commit sets the property "max-width" as "important" to prevent this issue from occurring. task-5972284 Forward-Port-Of: odoo/odoo#250690
A test case was failing due to a missing accounting group during user creation, leading to an access error when attempting to create a journal entry. This change ensures the necessary group is assigned, resolving the test failure and preventing similar issues in the future.
Original PR description
The crash occurs due to the test case introduced in PR #246920. While creating the user, no accounting group was assigned, so when this user attempts to create a Journal Entry, an AccessError is raised. **Root cause:** - In the previous version, when a public user was created, the required groups for creating an account move were assigned by default. However, in the current version, only a single group is assigned by default, which is Role/Member. As a result, when attempting to create an account move, an access error. In this commit, the required accounting group is added during user creation to ensure the test runs correctly. Runbot-241930
A test in the sale_timesheet module was failing due to a dependency on the account_accountant (Invoicing) module. The fix ensures the Invoicing module is automatically installed during test execution, allowing the test to run successfully. This prevents disruptions to the testing process.
Original PR description
__ ## Error description When the test runs following a specific configuration, the field `invoicing_switch_threshold` isn't found. However, we have to keep this field in the test because we can't replicate the issue the test checks without it. ## Origin of the issue This field belongs to the `account_accountant` (Invoicing) module. However, `sale_timesheet` doesn't have a dependency on this module: there's only an auto install for `account_accountant` when installing the module from the front-end. Therefore, if we launch the test without the `account_accountant` auto install, it will fail. __ original commit: https://github.com/odoo/odoo/pull/250946/changes/52a9841c754466c2df65c75d13c9ed2ae86a51ce Forward-Port-Of: odoo/odoo#252772
This update resolves an issue where clicking 'View' links after deleting a website page (like 'ContactUs') didn't function correctly. The fix ensures that links redirect properly by using the correct model name in the URL, preventing broken functionality and improving the user experience.
Original PR description
**Steps to reproduce:** 1. Go to the list view of website pages. 2. Select the page "ContactUs". 3. Click Delete. 4. A warning dialog appears. 5. Unfold one of the lists of records where the page is used. **Issue** Clicking on a record link (for example, "View") does not redirect anywhere. This is due to the use of the model display name in url. caused by https://github.com/odoo/odoo/commit/de302c2d36305c0d7562572a30587641eabfe914 **Fix** Use the model_name instead of the display name in the URL. task-5880458 Forward-Port-Of: odoo/odoo#245932
This update resolves an issue in the GSTR report testing process. Previously, tests were incorrectly deleting tax information. Now, the system removes taxes from the account move line, ensuring more accurate report generation and compliance. This change improves the reliability of the GSTR reports.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834
A bug preventing the reset of the Lead Forward email template was resolved. This issue occurred due to a new validation check introduced in version 18.3. The fix ensures users can now correctly reset the template without encountering an error, maintaining proper email template functionality.
Original PR description
Steps to reproduce: - Create a lead > click on gear icon > Forward to partner - Send the forward and ensure there is at least one record of crm.forward.to.partner - Navigate to email templates technical settings menu and search for Lead Forward: Send to partner - Click on Reset Template in the template form Current behavior: - Validation Error thrown Expected behavior: - No validation error thrown and template is reset Note: MailTemplate._check_can_be_rendered was added in version 18.3 which checks for invalid object references when trying to alter + save templates. This template was out of date and fails the check Referenced PR: https://github.com/odoo/odoo/pull/176623 opw-6001560
This update corrects a recent change that removed a feature in the traceability report. The original fix, which limited breadcrumb size, was deemed a poor solution and has been reverted to restore the intended functionality. This ensures users can properly track component lots within the traceability report.
Original PR description
commit d7f81c25555c800bf296da2507d010257292aa55 It was removed in order to limit the breadcrump size. However it was a stupid solution and it's better to let the feature rather than limiting the breadcrump size. Forward-Port-Of: odoo/odoo#254330
This update corrects a minor issue in the Helpdesk module where ticket links were incorrectly identified as regular links instead of buttons. This change ensures that buttons within email templates function as expected, allowing users to properly interact with ticket information. The fix resolves a visual inconsistency and improves the user experience.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#107888
This update resolves an issue where GS1 barcode filtering would fail due to an error when a barcode was interpreted as a date. The fix prevents this error from blocking product filtering, ensuring accurate internal transfer operations. This improves the reliability of barcode scanning for inventory management.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update resolves a problem where tours on the website weren't loading translations correctly, particularly in newer Chrome versions. The fix adds a temporary step to ensure translations start loading promptly, preventing delays and interruptions during the tour experience. This ensures tours function reliably for all users.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/odoo#254210 Forward-Port-Of: odoo/odoo#253896
This update resolves a problem where tours on the website were failing to load translations correctly, particularly for new startup requests. The fix introduces a temporary step to ensure translations load before the tour begins, addressing an issue exacerbated by recent Chrome browser updates. This ensures tours function reliably for all users.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#110856 Forward-Port-Of: odoo/enterprise#110648