Friday, January 23, 2026
18 changes · 18.0
Enhancements to existing features
This update improves how product prices are displayed in Odoo. A new method, `_get_price_label_base_str()`, has been added to the product pricelist item model. This change allows for more flexible and customizable formatting of price labels, ensuring consistent and accurate presentation of pricing information.
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
Resolved issues and error corrections
This update fixes an issue where the system incorrectly prevented saving BOMs with byproducts having different cost shares based on product color attributes (e.g., white vs. black). The change ensures that the total cost share for a BOM's byproducts can exceed 100% when using different color variants, resolving a user-reported error and improving flexibility in product costing.
Original PR description
### Steps to reproduce: - In the settings enable By-Products - Create a product with an color attribute and 2 values: white, black - Create a bom for that products and add 2 by product lines: - 1 x…
### Steps to reproduce:
- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
- 1 x comp1 with a cost_share of 50% specific to the white att-value
- 1 x comp2 with a cost_share of 70% specific to the Black att-value
> Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.
### Expected behavior:
The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.
### Cause of the Issue:
Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202
### Fix:
Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a
opw-5499773
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where customer names containing reserved words (like 'constructor') caused errors in reporting. The fix uses a different object creation method to avoid conflicts with inherited properties, ensuring customer names with these words can now be used without technical problems.
Original PR description
Steps:
- Have a customer named "constructor" (or any valid json prototype key value)
- Install `sale_management`
- Create a sale order with "constructor"
- Open Reporting -> Customers
- Traceback `Caused by: TypeError: groupedDataPoints[key].push is not a function`
This problem occurs because we use the client name directly in an object, and “constructor” already exists in all objects but is not initialized correctly, which raises a traceback.
One solution is to use `let object = Object.create(null)` instead of `let object = {}`, which prevents inheritance of `Object.prototype` properties.
https://github.com/odoo/odoo/blob/5e74f04ff35ed3efa25be295567be41f42024692/addons/web/static/src/views/graph/graph_model.js#L451-L457
opw-5474691
Forward-Port-Of: odoo/odoo#245206This update fixes an inconsistency in how product pricelists are assigned to partners. Previously, EU partners were incorrectly assigned a specific pricelist, while others weren't. This change ensures that EU partners automatically use the default pricelist, streamlining pricing and avoiding manual adjustments.
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)
This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on default settings for partners without country information. The fix ensures consistent ordering by aligning pricelist sequences, resolving a minor technical issue without impacting core functionality.
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
This update resolves an issue where rounding errors in currency calculations were causing the system to incorrectly remove small cash differences from reports. The fix ensures that even minor discrepancies, resulting from rounding, are accurately identified and reported, preventing unintended removal of cash transactions. This improves the accuracy of our financial reporting.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update corrects a user experience issue where demo data included the name "Deco Addict," causing confusion. The name has been updated to "Acme Corporation" to align with standard demo data practices and prevent user misinterpretations. This ensures a cleaner and more reliable demo environment.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502
This update resolves a customer complaint regarding demo data. The name "Deco Addict" has been replaced with "Acme Corporation" to avoid confusion and ensure accurate test scenarios. This change improves the user experience and data integrity within our demo environment.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502
This update addresses a limitation in how users manage their consent for online account synchronization. Previously, a short-lived access token caused the synchronization link to break after 30 minutes. Now, a more stable consent token is used, linked to the user, ensuring a consistent and reliable synchronization process.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105202
This update enhances the security and reliability of our Peppol integration by implementing a safer method for server-initiated deregistration. The system now handles deregistration more gracefully, allowing users to re-register after a server-initiated step. This change was prompted by a previous incident and is designed to improve overall system stability.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#244575 Forward-Port-Of: odoo/odoo#239254
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations, specifically with multi-checkbox attributes having no values. The fix ensures that lines without values are excluded from the combination process, preventing the loop and improving system stability. This change impacts product configuration and ensures accurate attribute selection.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update resolves a test failure in Odoo's web_studio module caused by a missing dependency. The fix ensures that tests accurately check for the presence of required modules and their associated models, preventing false test failures. This improves the stability and reliability of the web_studio functionality.
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.
This update removes outdated test code related to exchange rate precision in the l10n_mx_edi module. The previous fix inadvertently left this older code in place, and this PR ensures the testing environment is clean and consistent. This improves the reliability of the Mexican tax reporting functionality.
Original PR description
The PR #102557 fixed an issue with exchange rate precision for Solution Factible. However, its forward ports for 18 (PR #104195) and saas-18.2 (PR #104673) did not properly delete some of the old test code. This PR deletes that code. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200)
This update resolves a bug where self-order kiosk tickets were printing blankly when a preparation printer was configured without product categories. The fix ensures that kitchen printers only print when a product category is defined, aligning with the expected behavior of the self-order system. This prevents blank tickets and improves the kiosk experience.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245193
This update resolves a technical issue that was preventing our project scheduling tests from running correctly. The fix ensures proper handling of spaces in test data, improving the reliability of our testing process and ultimately contributing to more stable project planning features. This change focuses on internal test improvements.
Original PR description
Fixes https://runbot.odoo.com/odoo/runbot.build.error/162366
This update corrects a bug where a delivery order's picking state would incorrectly update the serial number of a product. The fix prevents changes to the serial number when adding new moves to 'ready' pickings, ensuring accurate tracking of inventory and serial numbers. This improves data integrity and reduces potential errors in stock management.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993
This update replaces "Deco Addict" with "Acme Corporation" in various Odoo demo data sets to address a user complaint. This ensures demo data accurately reflects business scenarios and avoids confusion for users. The change improves the user experience and data consistency.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245434 Forward-Port-Of: odoo/odoo#245205
This update resolves a user complaint regarding test data that incorrectly included 'Deco Addict'. The company name has been updated to 'Acme Corporation' to align with demo and test environments, ensuring a more accurate and professional experience for potential users. This change improves data consistency and user perception.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105279 Forward-Port-Of: odoo/enterprise#105151