Tuesday, November 4, 2025
12 changes · 17.0
Resolved issues and error corrections
This change fixes an issue where some upgrade steps could run in a different order from one execution to another. By keeping the migration order stable, it helps ensure upgrades behave predictably and reduces the risk of inconsistent results during updates.
Original PR description
When we list the versions to upgrade we go over the values in `self.migrations[pkg.name]`. This object is a mapping of mappings `{script_location: {version: scripts_list}}`. The location could be `module` or `module_upgrades` for local scripts, or `upgrade` for scripts in any of the extra upgrade paths.
The problem is that if we have a minor version that matches a major one in different locations the order is non-deterministic. For example if we have a local upgrade script in `1.2`, and an extra upgrade script in `16.0.1.2`. Both `version` keys (`1.2` and `16.0.1.2`) will resolve to `16.0.1.2` when ordering. But the order they _actually_ appear in the set of versions is non-deterministic --due to the `set` implementation in Python.
The solution is to use a container that keeps the order, in this case a `dict`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234124This fix ensures each dropdown option on website forms is translated and saved independently. As a result, changing one option no longer causes the other translated options to reset when switching languages.
Original PR description
__Current behavior before commit:__ [This PR] made the `<select>` field translatable by adding `select` and `option` to `TRANSLATED_ELEMENTS` and implementing a temporary element to handle the…
__Current behavior before commit:__ [This PR] made the `<select>` field translatable by adding `select` and `option` to `TRANSLATED_ELEMENTS` and implementing a temporary element to handle the frontend translation. Consequently the method `translate_xml_node` considers the `<select>` field translatable as a whole. Editing the text of one option therefore resets the translation of all the other options as well. __Description of the fix:__ - Remove `select` and `option` from `TRANSLATED_ELEMENTS` so each option is considered as an independant translatable term. - Adapt the temporary element hack consequently as well as its CSS. - Remove the now useless `SelectTranslateDialog`. __Steps to reproduce:__ 1. Add a form snippet to a website page. 2. Add a selection field to the form. 3. Translate the options in another language. 4. Leave Translation mode and go back to Edit mode. 5. Edit one of the option. 6. Change the website back to the second language. => All the options of the select field are reset. [This PR]: https://github.com/odoo/odoo/pull/117519 task-5116823
When a sales order’s pricelist is updated, optional product prices are now recalculated correctly. This prevents optional items from keeping an outdated price or incorrectly staying at zero, so pricing shown to customers stays accurate.
Original PR description
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist -…
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist - Click on 'Update Prices' - Notice the optional product price won't change ### Cause: When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation. If sale_subscription is installed we will set the product's prices to 0 https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 so the price of the 'Optional product' SOL will change but will be equal to 0 ### Fix: An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed opw-5058609
This fix ensures sales orders are marked as invoiced when no further stock operations are expected, even if the full ordered quantity was not delivered. It helps keep order and invoicing status accurate, reducing confusion for sales and accounting teams.
Original PR description
If no other operations are expected on the picking, even if the full quantity wasn't delivered, the order should be marked as invoiced. task-4607401 Fixes #144485 Partial revert of #115871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents DHL shipping requests from failing when prices or weights are calculated with very small decimal differences. It improves reliability for delivery validation so shipments can be processed without avoidable errors.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193
This change fixes an issue where customer details could be updated in two separate steps, causing inconsistent Peppol verification data and validation errors. It helps ensure partner information is saved consistently, reducing failed verifications for affected users.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276
This fix prevents products that have been archived from being included in point of sale combos. It helps avoid accidentally selling items that the business has marked as inactive.
Original PR description
Before this commit, when a product used in a combo was archived, it was still possible to sell it through the combo in the PoS. After this commit, archived products are excluded from combos, preventing them from being sold inadvertently. opw-5180301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the delivery date on customer invoices from being unintentionally reset when the invoice is confirmed. It matters because it preserves the correct delivery information for billing and accounting, avoiding confusion and manual corrections.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable anglo-saxon accounting;
2. have a product category with automated AVCO;
3. assign category to a deliverable product;
4. set product to invoice on delivery;
5. add product to a sales order;
6. confirm order & delivery;
7. create invoice;
8. change the delivery on the invoice;
7. confirm the invoice.
Issue
-----
The delivery date gets reset.
Cause
-----
Commit 818cf04f05767 added `delivery_date` as a permanently protected field when modifying moves or move lines, protecting the records on `write`. With anglo-saxon accounting however, new move lines are created when confirming an invoice, which in turn recalculate the delivery date, as `_get_protected_vals` isn't used for their move on `create`.
Solution
--------
Add `self.env['account.move'].protecting(_get_protected_vals({}, moves))` when creating new lines for a move, to avoid recomputing fields that should always be protected.
opw-4965036Fixed an issue where available stock was not refreshed in Barcode operations after changing the product or source location. This ensures users see the correct quantities when creating or editing internal transfers, reducing confusion and mistakes during warehouse work.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624
Point of Sale now correctly recognizes product packaging when scanned with a GS1 barcode and adds the related quantity automatically. This fixes a checkout issue that could previously require manual quantity adjustment, making barcode scanning faster and more reliable.
Original PR description
Before this commit, scanning a GS1 barcode for a product packaging did not add the quantity. opw-5003035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an issue where users without Employees access could not select an employee in certain forms, especially on mobile. The system now correctly shows the available public employee information instead of incorrectly returning no results.
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115
Quality checks created per quantity now use the correct company for the related stock operation. This prevents confirmation errors in multi-company setups when users switch between companies.
Original PR description
When creating quality checks per quantity, a multi-company error occurs if the active company differs from the one defined on the control point. Steps to reproduce: - Create a Quality Control Point for Company B and Product Table for the receipt operation with a per-quantity control. - Create a receipt in Company B for this product but leave it in draft. - Switch to Company A and try to confirm → error. Root cause: The company_id was not set when creating the quality check, causing it to default to `env.company` (A) instead of the stock move line’s company (B). opw-86993