Daily updates from Odoo
Saturday, November 15, 2025
7 changes · master
Resolved issues and error corrections
Fixes an issue where the shop floor quantity edit pop-up showed the total backorder quantity instead of the amount remaining for the selected operation. This helps production teams record partial work accurately and avoid confusion during backorder processing.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#98775 Forward-Port-Of: odoo/enterprise#93599
This fix prevents the browser from reusing an outdated saved copy when a spreadsheet tab is duplicated. Users should now see the latest spreadsheet changes in duplicated tabs, reducing confusion and potential work errors.
Original PR description
It happens that browser may use a cache if there's no explicit cache control/expiration time: https://httpwg.org/specs/rfc9111.html#heuristic.freshness Steps to reproduce (non-deterministic): - create a new spreadsheet - do some changes, edit a few cells - right click on the tab and hit "Duplicate" => the spreadsheet is not up-to-date on the duplicated tab. The browser loaded the response from "disk cache" instead of fetching the latest data from the server. I'm using Chrom Version 142.0.7444.162 (Official Build) (64-bit) We add an explicit cache control. Forward-Port-Of: odoo/enterprise#99426
Fixed an error that could occur when adding a user to a new database project before any databases were linked. The user management wizard now handles this empty state correctly, preventing an unexpected crash and allowing the workflow to continue.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Go to Databases; 2. open a new project; 3. enter any name, hosting provider & URL; 4. under User Management, click on "Add a user". Issue ----- Traceback: > `ValueError: Compute method failed to assign databases.manage_users.wizard(<NewId 0x71e8c0d8fd80>,).everywhere_user_ids` Cause ----- The `_compute_everywhere_user_ids` method computes the value of a non-stored field. Consequently, every record in `self` needs have some value assigned to `everywhere_user_ids` during the compute, but currently, if the `database_ids` field is empty, `continue` is used without assigning a value. Solution -------- If the record doesn't have any known `database_ids`, set `everywhere_user_ids` to `None`. opw-5170587 Forward-Port-Of: odoo/enterprise#99200
DHL shipment submissions now round prices and weights correctly before sending them to DHL. This prevents avoidable validation failures caused by tiny decimal precision differences, helping users validate deliveries more reliably.
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 Forward-Port-Of: odoo/enterprise#99482 Forward-Port-Of: odoo/enterprise#96012
The NACHA payment file now formats the company identification field according to official ACH rules. This helps payroll and payment files be accepted consistently by banks by using the correct spacing instead of zero-padding for this alphanumeric value.
Original PR description
According to https://achdevguide.nacha.org/ach-file-overview: - An alphanumeric field must be left-justified and post-padded with spaces. - A numeric field must be unsigned, right-justified and pre-padded with zeros. The Company Identification being an alphanumeric value (see https://achdevguide.nacha.org/ach-file-details), it should be left-justified and post-padded with spaces even in the type 8 record, like it is actually in the type 5 record. opw-5048564 Forward-Port-Of: odoo/enterprise#99469 Forward-Port-Of: odoo/enterprise#98922
Selecting an EasyPost carrier account in delivery method setup now works without triggering an error. This helps shipping configuration proceed smoothly when users load and choose EasyPost carrier accounts.
Original PR description
**Issue** A traceback occurs whenever a carrier is selected in the EasyPost delivery method. **Steps to reproduce** 1. Install the barcode application 2. Go to Settings > Inventory > enable…
**Issue** A traceback occurs whenever a carrier is selected in the EasyPost delivery method. **Steps to reproduce** 1. Install the barcode application 2. Go to Settings > Inventory > enable "Easypost" shipping connector 3. Go to Delivery Methods -> click "New" -> choose "Easypost" as provider 4. Fill in the API keys 5. Click "Load your Easypost carrier accounts" and select a carrier → A traceback occurs **Cause** The error occurs at: https://github.com/odoo/enterprise/blob/39320569a3561f133000ded00800f705d9507ac2/delivery_easypost/static/src/components/carrier_type_selection/carrier_type_selection.js#L15 `ev` is expected to be a JSON object but is received as a string. The component extends `SelectionField`, which has been modified in [this commit](https://github.com/odoo/odoo/commit/0923409082ead5ffdf2c28f3b063fbd91ebce553): https://github.com/odoo/odoo/blob/5be6ef1ae3958a25e680f5fa30824fec57d63efe/addons/web/static/src/views/fields/selection/selection_field.xml#L9 **Solution** Adapt the `onChange` method to handle the argument type change. opw-5170833 Forward-Port-Of: odoo/enterprise#98678
Opening Indian tax returns no longer fails due to an internal data formatting issue in validation checks. The update also ensures UQC check results open the correct unit of measure records, making it easier for users to review and correct reporting data.
Original PR description
This commit fixes traceback while opening the tax return for indian company and also fixes incorrect model name for uqc check. Traceback
```py
File /usr/lib/python3.12/json/encoder.py, line 180, in default
raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type DomainAnd is not JSON serializable
```
This Traceback is due to the use of `Domain.And` in the check of uqc code from commit :-
https://github.com/odoo/enterprise/commit/5069c133def1ab9f3288fe42c9c97d192d263321
Reason for traceback
The checks uses `_get_records_action` to open the records which internally adds the `dict(self.env.context)` which does incorrect json serialization.
Also this commit replaces `uom.uom` model inplace of `account.move.line` to open uom instead of lines.
task-5267149
Forward-Port-Of: odoo/enterprise#99628