Thursday, March 12, 2026
63 changes · saas-19.1
Resolved issues and error corrections
This update resolves an error that occurred when viewing the shop page with products having no variants. Specifically, the system now correctly handles products without variants, preventing a display error and ensuring the 'Add to Cart' button is appropriately shown or hidden based on stock levels. This improves the overall stability and usability of the shop experience.
Original PR description
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product…
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product template` of type `Goods`. - Enable `Track Inventory`. - In the `Sales tab`, disable `Sell when Out-of-Stock`. - In the `Attributes & Variants` tab, add one attribute with two values and save. - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants. - Go to `Website` > `Shop`. **Error:** `ValueError: Expected singleton: product.product()` After [this commit], when opening the shop page, it calculates the quick add availability [1] for every product. It checks whether the product is sold out [2] to determine whether the quick add to cart button should be displayed or not. Since the product has no variants, it raises the error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4]. This commit ensures that if a product has no variants, it is treated as sold out. As a result, the quick add to cart button is not shown, as in the previous version. [this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c [1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39 [2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33 [3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41 [4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403 sentry-7287364112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250373
This update resolves an issue preventing proper printing using wkhtmltopdf. The HTML editor now utilizes a static file box instead of an embedded component, restoring its printing capabilities. This change was previously addressed in another pull request and is aligned with the Enterprise version.
Original PR description
Purpose of this commit: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/odoo/pull/216572 enterprise: https://github.com/odoo/enterprise/pull/108999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251098
This update resolves a technical problem that was preventing users from correctly printing knowledge articles. The team reverted a previous change that caused issues with the printing process using wkhtmltopdf. This ensures all knowledge articles can be printed without errors.
Original PR description
### Purpose of this PR: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/enterprise/pull/88929 community: https://github.com/odoo/odoo/pull/251098 Forward-Port-Of: odoo/enterprise#108999
Odoo has updated its security protocols to prevent errors when calling methods remotely. Specifically, `@classmethod` and `@staticmethod` methods, which were previously accessible, are now restricted. This change ensures that only standard methods can be called remotely, enhancing the overall security and stability of the system. This update resolves a previous error related to calling the `is_transient` method.
Original PR description
Access /doc, see that `is_transient` is listed, call it via JSON-2. Error 422 "Unprocessable Entity": too many positional arguments.
The `is_transient` method is defined as follow:
```py
@classmethod
def is_transient(cls) -> bool:
""" Return whether the model is transient.
See :class:`TransientModel`.
"""
return cls._transient
```
It is a `@classmethod` and take no argument. Only regular methods can be called remotely. The `@classmethod` and `@staticmethod` (actually, all methods that are defined on the class, and not on the instance) are now considered private.
Reported-by: Florent Xicluna <florent.xicluna@camptocamp.com>
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#252739This update fixes an issue preventing UK users from correctly accessing Stripe funding instructions. The team reworked the testing framework to specifically handle UK requirements and added a secondary check for Euro currency to ensure accurate funding instructions are provided. This improves the user experience for UK customers.
Original PR description
### [IMP] hr_expense_stripe: Rework tests for UK Rework the test framework to handle the United Kingdom specific tests ### [FIX] hr_expense_stripe: Fix UK account creation Add UK account creation funding instructions as it was made available to us by Stripe ### [FIX] hr_expense_stripe: Fix funding instruction EU Before this commit: The funding instructions were using the country group Europe as a reference to see if the country should use the EU funding instructions The issue comes from the fact that a lot of people remove their country from that country group, locking themselves out of stripe issuing EU. This adds second way of telling the user is in the EU flow if their stripe currency is set to Euros. Forward-Port-Of: odoo/enterprise#109667
A minor warning appearing on Odoo website pages has been fixed. This warning related to a JavaScript error (empty string passed to getElementById()) only occurred when website URLs didn't include a hash. This change ensures a smoother user experience and prevents potential issues.
Original PR description
Since [34df6f8d], a warning `Empty string passed to getElementById().` appears on every website page when there is no hash in the URL. That's not the case anymore after this commit. [34df6f8d]: https://github.com/odoo/odoo/commit/34df6f8d6efc879bef00228b19df04db6c884089 Forward-Port-Of: odoo/odoo#252181
This update corrects tax reporting templates for Belgium, Netherlands, Luxembourg, and France, ensuring accurate UBL/CII tax category and exemption reason codes are used. Specifically, the BE tax template now correctly assigns tax codes for all taxes, resolving previous inconsistencies and improving compliance with local tax regulations. This ensures accurate financial reporting and reduces potential tax discrepancies.
Original PR description
Before this commit : NL,FR,LU tax templates did not define the UBL/CII tax category and exemption reason codes. In BE tax template, all cocontracting taxes had "AE" tax code and "VATEX-EU-AE" tax exemption reason code, even for non-0% cocontracting taxes. Some other taxes didn't have the correct codes. After this commit : All relevant NL,FR and LU tax templates now define their UBL/CII tax category and exemption reason codes. Specific reason codes are assigned where applicable. In BE tax template, taxes are now corrected, all taxes have their relevant tax codes. task-4976471 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#250013
This update resolves an issue where users could inadvertently add partners from different companies when managing multiple companies. Previously, the system didn't properly restrict partner selection, leading to potential data inconsistencies. This fix ensures partners are correctly associated with their respective companies, improving data accuracy and reliability.
Original PR description
Before this commit, it was possible to add a partner that was from another company when multiple companies were selected. task-5941113 Forward-Port-Of: odoo/enterprise#108048 Forward-Port-Of: odoo/enterprise#107546
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime from processing correctly. The change ensures the system recognizes only the approved string value for this regime, resolving a validation error during invoice signing. This ensures compliance with Ecuadorian tax regulations and proper invoice processing.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update resolves a technical issue that caused errors when opening certain records with incorrectly formatted HTML. The fix ensures that all list items have a minimum content, preventing tracebacks and improving the stability of record views. This change ensures a smoother user experience for all users.
Original PR description
Steps to reproduce:
- Open a record containing the following invalid HTML:
```html
<ul>
<li>1</li>
<li class=oe-nested></li>
</ul>
```
Description of the issue:
- A traceback occurs when opening a record with this html.
Cause:
- The provided HTML is invalid because an `<li>` element must contain at least one child node. In this case, the `<li>` element has no children. As a result, when `isListElement` tries to access the `nodeName` of its child, a traceback occurs because the `<li>` has no child node.
Solution:
During normalization. If an `<li>` element has no children, call `fillEmpty` so that a `<br>` element is inserted. This ensures the `<li>` contains at least one child and is no longer invalid.
task-6012663This update optimizes how Odoo identifies user devices, leading to faster data retrieval when viewing user sessions and devices. Previously, a performance bottleneck prevented efficient indexing, but this change utilizes a more direct approach using IDs, resulting in a noticeable improvement in speed. This ensures smoother user experience and faster reporting.
Original PR description
When a view of `res.users` with the `session/device_ids` field(s) is used, the ORM will translate the `One2Many` relationship by performing a query that uses the `id` column to retrieve the rows. The problem is that before this commit, it is impossible for postgresql to use the index on this column, because the value is retrieved via aggregation. This commit improves the performance of these models by performing deduplication without using the `GROUP BY` clause, but using `NOT EXISTS` instead. Note: It is necessary to perform the missing aggregations in a computed field (for the `first_activity` field). Task-6002927
This update resolves an issue where the blog module would display an error when a user entered an invalid URL. The fix ensures that the blog module doesn't attempt to process URLs with missing or incorrect tag IDs, improving the overall stability and user experience of the blog feature.
Original PR description
Steps to reproduce: - Install `website_blog` module(with demo data) - Change URL (eg: /blog/tag/hotels) Traceback: `AssertionError: Invalid falsy real id` We are encountering this error because [active_tag_ids] contains `[None]`, and falsy IDs are no longer allowed in `browse()`. [active_tag_ids]: https://github.com/odoo/odoo/blob/4e4d1dba32ef45567eda004fc1a3584591508720/addons/website_blog/controllers/main.py#L83 sentry-7289765426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where spreadsheet thumbnails sometimes failed to save correctly due to a temporary disconnection. The fix ensures that screenshots are reliably captured, preventing thumbnail generation failures and improving the user experience when saving spreadsheet snapshots. This addresses a minor disruption for users.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves an issue where Dutch tax returns appeared to be submitted in the Odoo system but weren't actually being transmitted to the relevant tax authorities. The fix ensures that the necessary XBRL export is triggered when a Dutch tax return is submitted, aligning the UI with the actual submission status.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#110015 Forward-Port-Of: odoo/enterprise#109691
This update resolves an issue where sale orders would fail to confirm if a product wasn't added before confirmation. The tour tests have been updated to ensure product additions are fully processed before order confirmation, preventing order drafts and ensuring the tour completes successfully. This impacts the sale and purchase workflows.
Original PR description
There is an inaccuracy in the steps of the tour: - test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step…
There is an inaccuracy in the steps of the tour: - test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step confirms the order without waiting for all the associated onchanges to be taken into accounts: https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale_management/static/tests/tours/sale_flow_tour.js#L14-L20 https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale/static/src/js/tours/tour_utils.js#L27-L47 In the case where the confirmation happends before the product edition is taken into account, the order fails to confirm and stays in draft which makes the rest of the tour fails. Note: The same issue could happen at some point on the equivalent purchase test, so that we also modify the test: - test_basic_purchase_flow_with_minimal_access_rights runbot-241198 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252154
A technical update resolved an issue preventing the Quote Builder from generating PDF quotes, which was causing errors. This change updates the PDF generation library to a compatible version and adds a necessary field definition to ensure proper PDF creation.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
This update fixes a UI bug that occurred when changing wage intervals in the employee payroll settings. The issue stemmed from extra text being inserted into the employee form, causing errors. The fix removes this extraneous text to ensure correct wage calculations.
Original PR description
Bug production steps: First, I created a new db with saas-19.1 db from runbot, from payroll->employee->Payroll tab in form view, when you change wage interval to another thing than 'month' error occurs Bug cause: There is another text like /2 months, /2 weeks are inserted from hr_employee_views in the hr_contract_salary_payroll to the XML of the employee form view. Bug solution: Removing the corresponding XML insertions. task - 5469378
This update resolves an issue where point of sale reports were incorrectly identifying orders due to date precision. The fix ensures the refund order is always prioritized during report generation, guaranteeing accurate reporting of transactions. This improves the reliability of sales data.
Original PR description
The test test_refund_multiple_products_amounts_compliance was doing a search on 'report.pos.order' and was wrongly assuming that the first order in the recordset returned was the refund one and the other one was the original order. This was because the search is ordered by date descending and the refund order is created after the original order. However, in some cases, the date of the refund order can be the same as the date of the original order cause the dates are precise to the second which can lead to a the records returned by id ascending which would give the original order first. This commit adds an explicit order by id descending as second choice to ensure that the refund order is always returned first. runbot-error: 238454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a naming inconsistency within the HR payroll module. The template was previously identified with a longer, less clear name. This change simplifies the naming to align with standard Odoo module practices, ensuring better organization and easier identification of the module.
Original PR description
Currently in hr_payroll, the template name is set as l10n_be_hr_payroll.DropdownSelectionBadge. Generally, it should follow the module name. Therefore, in this commit, I replaced l10n_be_hr_payroll with hr_payroll
This update corrects a bug where users without HR document centralization enabled were seeing all documents, not just their own employee documents, when using the 'documents' smart button. The fix restores the intended behavior for companies without this HR setting, ensuring employees only access their own files. This resolves a previous issue impacting document access.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update reduces the visual prominence of reply text in conversations, making it easier for users to read and manage lengthy threads. By lowering the opacity and restoring it on hover, the changes enhance the overall user experience and reduce visual fatigue when reviewing conversations with many replies.
Original PR description
Before this commit, conversations that had a lot of replies were quite exhausting. This comes from the visual of "reply" text that had its text that is too visible, contributing to having a feeling that there's too much text on the screen. This commit fixes the issue by reducing the visibility of reply to part, so that it's easier to read conversations with lots of reply-to. Opacity has been reduced to keep the reply-to content recognizable enough, and this reduced visibility is canceled on mouse-hover, also making the hover effect on reply-to more apparent. Before / After <img width="604" height="520" alt="Screenshot 2026-02-27 at 19 06 03" src="https://github.com/user-attachments/assets/04a118bc-5fc0-47d6-ad62-3b7e26f835da" /> <img width="604" height="525" alt="Screenshot 2026-02-27 at 19 05 50" src="https://github.com/user-attachments/assets/37974f2c-054c-44bc-bf9a-044825908abc" /> Forward-Port-Of: odoo/odoo#251295
This update resolves a technical issue where products weren't correctly marked as 'available' in self-order tests. This prevented some products from loading properly in the self-ordering frontend, causing test failures. The fix ensures all products are correctly identified as available, improving the reliability of self-order functionality.
Original PR description
In some self order tests, available in pos was not set to true which could cause some errors in the tests as some products were not loaded in the self frontend. runbot-error: 241086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252985
This update corrects a bug that prevented users from successfully removing a company association from expense records. The fix ensures that the system handles company removal correctly, preventing a technical error that previously disrupted the process. This improves the reliability of expense record management.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update corrects a visual issue where the unit price wasn't shown on product pages when using the 'boxed' layout in the ecommerce section. The fix ensures all layout styles display the crucial unit price information for customers, maintaining a consistent and informative shopping experience. This resolves a prior bug introduced during a recent website update.
Original PR description
### Issue before the commit: In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed. ### Steps to reproduce the issue: - Download website and…
### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.
### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style
### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.
### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.
### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout:
```
<small t-if="combination_info.get('base_unit_price')"
class="ms-1 text-muted o_base_unit_price_wrapper d-none">
<t t-call="website_sale.base_unit_price">
<t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
</t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />
After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />
opw-5920598
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250319This update resolves an issue where Odoo invoices for Danish companies were incorrectly formatted according to Peppol standards. The change skips adding redundant PartyIdentification information, preventing a technical error and ensuring compliance with regulations. This ensures smooth invoice processing when submitting to Peppol.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737