Monday, January 26, 2026
14 changes · saas-18.4
Enhancements to existing features
This update makes product price label wording easier to customize for specific business needs. It is a small internal improvement that helps future extensions adjust pricing displays without changing the core pricing logic.
Original PR description
Add `_get_price_label_base_str()` method in order to exend it @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243861
Resolved issues and error corrections
The website image gallery carousel template was corrected to avoid unwanted placeholder text appearing as a class and to restore missing spacing. This helps pages using the gallery snippet render more cleanly and consistently for visitors.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#241785
This fix ensures the right activity plan is assigned when several scheduling assistants are used at the same time. It helps prevent incorrect follow-up plans from being applied, reducing confusion for users managing activities.
Original PR description
Description of the issue/feature this PR addresses: Same pattern as in https://github.com/odoo/odoo/pull/189843 but for _compute_plan_id method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243307
Argentina localization taxes marked as 0% non-taxable, not applicable, or exempt are now treated as percentage-based zero-rate taxes instead of fixed taxes. This ensures they remain available in workflows such as down payments, preventing missing tax information on affected documents.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245570 Forward-Port-Of: odoo/odoo#245252
When the message list cannot load, users now see the actual error details instead of only a generic failure message. This helps users and support teams understand persistent mail issues faster and decide what action is needed.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244094 Before this commit, when message list failed to load, it just displays a "Ann error occurred" generic message with a retry button. This assumes that error happens rarely and when so this is temporarily. However some errors are persistent and it's frustrating to have no clue on why there's error or what may have caused it. This commit shows the `Error.toString()` from fetch message RPC failure on UI, so that there's a clue on the reason the fetch of messages failed. Before / After <img width="305" height="67" alt="Screenshot 2026-01-20 at 15 10 38" src="https://github.com/user-attachments/assets/34c546df-71e6-4055-9f85-8d85a9c89b35" /> <img width="334" height="100" alt="Screenshot 2026-01-20 at 15 09 07" src="https://github.com/user-attachments/assets/5fadd0b7-7ea0-43ca-8c28-0ac1d33650ff" /> Forward-Port-Of: odoo/odoo#245150 Forward-Port-Of: odoo/odoo#244754
This fixes inconsistent price list handling when new contacts are created with no matching regional price list or no country. Contacts will no longer appear to have a manually assigned price list when they are simply using the default, reducing confusion and keeping customer records cleaner.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4.…
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4. create a new partner in a EU country; 5. create a new partner outside a EU country; 6. create a new partner without a country. Issue ----- Inconsistent behavior: - EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`. - The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them. Cause ----- In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it. Solution -------- Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`. > [!Note] > An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states: >> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view. > > This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`. opw-5385213 Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test) Forward-Port-Of: odoo/odoo#245669 Forward-Port-Of: odoo/odoo#241736
The Time Off form now displays sickness relapse fields on their own line instead of crowding the attachment area. This prevents confusion for Belgian employee leave requests after long sickness-related time off.
Original PR description
Bug production steps: Select employee works in Belgium company, go to timeoff and approve >= 1 months time off and select new timeoff after 1-2 days and there Sickness Relapse fields occur in the shifted UI. Bug cause: The field sickness_relapse added after attach file part, before there was label for the attach file part and it was occupying 2 columns, after removing column it occupies only 1 and the first part of the boolean sickness relapse fields come next to the attach file part. Bug solution: Make the colspan 2 for the attach file part, by that way the sickness_relapse will start from the below line. task - 5493425 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#243753
This fix prevents certain connected printers from causing an error when their connection details are refreshed. It helps keep IoT printer handling stable in an uncommon edge case involving printer connection protocols.
Original PR description
This commit fixes an edge-case between the disconnect counter logic, and the logic added in odoo/odoo#224200 to prevent printers switching between `lpd` and `socket` protocols. In this case, a device is returned that only has the `identifier` key set. Because the driver has already been instantiated, this didn't break anything before, but now it also clears the `disconnect_counter` key, leading to a traceback on the next iteration of the interface when it tries to check the `disconnect_counter`. The fix is simply to include the `disconnect_counter` as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an unexpected system error when users create or edit inherited views with missing XPath details. Instead, Odoo now shows a clear validation message, helping administrators identify and correct the issue without a crash.
Original PR description
Currently, an error occurs when a user creates an inherited view. **Steps to Reproduce:** - Go to `Settings > Technical > User Interface > Views`. - Create a new view by entering `name` and selecting…
Currently, an error occurs when a user creates an inherited view.
**Steps to Reproduce:**
- Go to `Settings > Technical > User Interface > Views`.
- Create a new view by entering `name` and selecting any `inherited view`.
- In the `Architecture`, enter the below code:
```
<xpath position="replace">
<field name="name"/>
</xpath>
```
- Now save the view.
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
Cause:
As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.
This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.
[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145
[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76
[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78
[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384
sentry-7161414430
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242203This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on default partner settings. The fix ensures consistent pricelist ordering, resolving a minor issue that could have affected subscription pricing calculations. This change improves the reliability of the test environment.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736 Forward-Port-Of: odoo/enterprise#105457 Forward-Port-Of: odoo/enterprise#103116
This update resolves an issue preventing the applicant tour from completing correctly when a company is configured as a US entity. The change adjusts the tour's logic to account for the additional documentation required in the US salary configuration, ensuring a smoother experience for new applicants.
Original PR description
- purpose: changing the company in the `hr_contract_salary_applicant_flow_tour` from a Belgian company to a US company so the tour doesn't fail because of additional documents in the Belgian salary configurator task-id : task-5038278
This update fixes an issue where the 19%I tax code (9) was missing from Datev exports for expense journal entries. The problem stemmed from how payment amounts were aggregated, leading to a loss of tax information. This ensures accurate tax reporting in Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
This update resolves a test failure in the web_studio module caused by a missing dependency. The fix ensures that all required modules are included in the test, preventing false failures and improving test reliability. This ensures consistent test results and prevents disruptions to the system.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105408 Forward-Port-Of: odoo/enterprise#104879
This update corrects an error that prevented the creation of new contract templates in the US payroll module. The system was incorrectly enforcing a requirement for a filing status, which doesn't apply to templates. This change ensures that contract templates can now be created without causing errors, aligning with the correct process of determining filing status per employee.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566