Daily updates from Odoo
Navigate
Branch
Sunday, March 8, 2026
10 changes
3 changes
Resolved issues and error corrections
This update resolves an issue where updating product quantities in sales orders could result in incorrect final quantities. The fix ensures that quantity updates are processed sequentially, preventing delays and guaranteeing accurate order totals. This improves order accuracy and reliability for our users.
Original PR description
Issue: --- Concurrent qty update might cause issue. Steps to reproduce: --- 1- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot. 2- Create a…
Issue: --- Concurrent qty update might cause issue. Steps to reproduce: --- 1- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot. 2- Create a SO. 3- On SOL creation, click on Catalog. 4- Copy the number 100 and click on catalog records fast and paste the number rapidly. Repeat this for all records of the page. 5- Go back to SO. You might find some lines with qty = 1. Cause: --- This is a concurrency issue. In the faulty cases, `update_order_line_info` setting quantity to 1, takes a few seconds to resolve, while the update setting quantity to 100 resolves faster (around 200ms). This cause the SOL final quantity set to 1. As an example you could see two `update_order_line_info` requests for the same `product_id`, first one setting quantity to 1 and second one to 100, in which first one resolves faster. <img width="912" height="316" alt="image" src="https://github.com/user-attachments/assets/219d2d10-32bf-490f-9f2c-a6229d60b991" /> <img width="927" height="328" alt="image" src="https://github.com/user-attachments/assets/1f0bddaf-e7d0-4311-b458-4416d77562c6" /> Fix: --- We can chain RPC calls to ensure that each request is completed before starting the next one. opw-5861412 Forward-Port-Of: odoo/odoo#250104
This update resolves a technical issue that caused tracebacks when invoicing kit products (with multiple components and AVCO or FIFO valuation) in Odoo. The fix ensures accurate cost of goods calculations for these scenarios, preventing errors during invoicing.
Original PR description
**Issue**: The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback **Steps to reproduce**: - Create a kit product with 2 components: - Inventory…
**Issue**:
The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback
**Steps to reproduce**:
- Create a kit product with 2 components:
- Inventory tracking enabled
- Use a category configured with AVCO and Perpetual (at invoicing) valuation
- Create a SO for the kit product and confirm it
- Go to the associated delivery and validate it
- Create and post the invoice on the so -> A traceback occurs
**Cause**:
In `_get_cogs_price_unit`, the code accesses `self.product_id.cost_method` assuming a singleton: https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/stock_move.py#L245 but `self.product_id` can be a multi-recordset when the sale line corresponds to a kit with multiple components https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/account_move_line.py#L67-L68 https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/sale_stock/models/account_move.py#L155-L156
which causes the traceback.
**solution**
The solution has been inspired by this:
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228
opw-5880383
Forward-Port-Of: odoo/odoo#247775This update fixes a bug in Point of Sale where a warning wasn't displayed when selling products with unique serial numbers and quantities greater than one. Previously, the system didn't alert users that they were using only one serial number for multiple products. This change ensures proper warnings are shown, preventing potential errors during sales.
Original PR description
## Issue In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is…
## Issue
In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is given.
## Steps to reproduce
1. Install Point of Sale (`point_of_sale`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a PoS product P
- Tracked *By Unique Serial Number*
- Update its quantity and create a few serial numbers
4. In the Point of Sale, select product P and set a serial number, then update the quantity to 2.
5. **The _Valid product lot_ icon next to the product is still green. We can also go to the payment screen without any warning, even though only one serial number was selected for two products.**
## Cause
The color and name of the icon displayed next to the serial tracked product is decided here:
https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9-L14
The `PosOrderLine.hasValidProductLot` is defined here:
https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/models/pos_order_line.js#L333-L341
The very first condition of this method makes the icon green as long as one serial number is selected.
opw-5486210
Forward-Port-Of: odoo/odoo#2469303 changes
Resolved issues and error corrections
This update resolves an issue where Romanian customers without a company registry were incorrectly assigned the default VAT instead of the standard VAT. The fix removes a redundant condition that was introduced during a previous update, ensuring accurate VAT assignment based on customer VAT status.
Original PR description
Problem --------- In a recent fix, in the Tax Scheme customer node, the scheme type was recomputed correctly depending on the companyID node. However, during the fix, a condition was wrongly introduced. This will lead to some issue: when a customer has no VAT, he should be given the default VAT. However, due to condition, the customer gets given the Default VAT only when he does not have a vat NOR A COMPANY REGISTRY. Solution --------- Remove the condition no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252475
This update fixes a problem where concurrent changes to product quantities in the catalog could result in incorrect final quantities being displayed in sales orders. The fix ensures that quantity updates are processed sequentially, preventing this inconsistency and improving order accuracy. This resolves a potential issue impacting order fulfillment.
Original PR description
Issue: --- Concurrent qty update might cause issue. Steps to reproduce: --- 1- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot. 2- Create a…
Issue: --- Concurrent qty update might cause issue. Steps to reproduce: --- 1- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot. 2- Create a SO. 3- On SOL creation, click on Catalog. 4- Copy the number 100 and click on catalog records fast and paste the number rapidly. Repeat this for all records of the page. 5- Go back to SO. You might find some lines with qty = 1. Cause: --- This is a concurrency issue. In the faulty cases, `update_order_line_info` setting quantity to 1, takes a few seconds to resolve, while the update setting quantity to 100 resolves faster (around 200ms). This cause the SOL final quantity set to 1. As an example you could see two `update_order_line_info` requests for the same `product_id`, first one setting quantity to 1 and second one to 100, in which first one resolves faster. <img width="912" height="316" alt="image" src="https://github.com/user-attachments/assets/219d2d10-32bf-490f-9f2c-a6229d60b991" /> <img width="927" height="328" alt="image" src="https://github.com/user-attachments/assets/1f0bddaf-e7d0-4311-b458-4416d77562c6" /> Fix: --- We can chain RPC calls to ensure that each request is completed before starting the next one. opw-5861412 Forward-Port-Of: odoo/odoo#250104
This update fixes a bug in the Point of Sale where a warning wasn't displayed when selling products with unique serial numbers and quantities greater than one. Previously, the system didn't alert users that they were using only one serial number for multiple products. This change ensures accurate tracking and prevents potential errors during sales.
Original PR description
## Issue In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is…
## Issue
In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is given.
## Steps to reproduce
1. Install Point of Sale (`point_of_sale`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a PoS product P
- Tracked *By Unique Serial Number*
- Update its quantity and create a few serial numbers
4. In the Point of Sale, select product P and set a serial number, then update the quantity to 2.
5. **The _Valid product lot_ icon next to the product is still green. We can also go to the payment screen without any warning, even though only one serial number was selected for two products.**
## Cause
The color and name of the icon displayed next to the serial tracked product is decided here:
https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9-L14
The `PosOrderLine.hasValidProductLot` is defined here:
https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/models/pos_order_line.js#L333-L341
The very first condition of this method makes the icon green as long as one serial number is selected.
opw-5486210
Forward-Port-Of: odoo/odoo#2469301 change
Enhancements to existing features
This pull request enhances the account_edi_ubl_cii module by completely separating the BIS3 export process. It deprecates several outdated functions related to BIS3 UBL generation, streamlining the export process and improving accuracy. This change ensures compliance with BIS3 standards for invoices.
Original PR description
Deprecate: _ubl_add_base_line_ubl_values_item _ubl_get_line_item_node _ubl_add_base_line_ubl_values_price _ubl_add_values_payable_amount_tax_withholding _ubl_add_values_payable_rounding_amount _ubl_add_values_allowance_charge_early_payment _ubl_add_values_tax_currency_code_company_currency_if_foreign_currency _ubl_add_values_tax_currency_code_company_currency _ubl_add_values_tax_currency_code_empty _ubl_add_values_tax_currency_code --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249823
1 change
Resolved issues and error corrections
This update resolves a problem causing the floor screen to repeatedly reload. The issue stemmed from a code change that incorrectly modified appointment times, triggering an infinite loop of re-renders. This fix ensures the floor screen displays accurate appointment information without unnecessary updates.
Original PR description
Infinite re-rendering in floor_screen.
Root cause: `getFirstAppointment` mutates reactive model state
(appointment.start) during rendering:
```
appointments.map((appointment) => {
if (appointment.start < startOfToday) {
appointment.start = startOfToday; // <= mutates reactive state!
}
});
```
And `startOfToday` is set by
`DateTime.now().set({ hours: 0, minutes: 0, seconds: 0 })`
Which doesn't zero milliseconds, so each render creates a new
`startOfToday` with a later millisecond value.
The comparison `appointment.start < startOfToday` keeps being true
triggers another write => another re-render => infinite loop.1 change
Documentation and clarification updates
This pull request represents a contribution from new developer, Carlos Montilva. It includes documentation updates related to his onboarding and adherence to Odoo's contribution guidelines. This change ensures proper tracking of new contributors and maintains compliance with Odoo's development processes.
Original PR description
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
1 change
Resolved issues and error corrections
This update optimizes the process of validating journal entries for ZATCA compliance, addressing a previous memory issue that caused slowdowns with large journals. By directly searching for relevant documents, the system now uses significantly less memory and avoids performance bottlenecks, ensuring smoother onboarding for users.
Original PR description
Behavior before: Sanity check looped over all account moves of the journal, filtering in Python for ZATCA documents. This caused memory errors when the journal had hundreds of thousands of moves. Behavior after: The check now searches directly on l10n_sa.edi.document with a domain that filters only relevant moves with state 'to_send', reducing memory usage and avoiding Python-level loops. Root cause: Loading all moves and their One2many edi_document_ids in memory for filtering caused excessive memory usage and MemoryError on large journals. OPW-5972073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251732