Daily updates from Odoo
Tuesday, July 14, 2026
6 changes · 17.0
Enhancements to existing features
This update makes the loading of availability information in the Manufacturing Order (MO) list view faster. Previously, this process was a significant delay, impacting user experience. By implementing a lazy loading approach similar to previous versions, this change dramatically improves the speed and responsiveness of the MO list view.
Original PR description
When loading the MO list view, loading the availability is what's taking the most time. Making this loading lazy as it was in 16.0 will greatly contribute to the UX. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Uruguayan electronic credit notes for original e-Tickets with a zero total now include the required reference amount field. This prevents tax authority rejections and lets businesses process these corrections without manual workarounds.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783
This update resolves a performance issue in the Point of Sale system related to concurrent sales of products. The previous approach caused delays and slowdowns for users, particularly when multiple sales locations were active simultaneously. This change reverts a previous fix to stabilize the system and improve overall responsiveness.
Original PR description
This reverts commit 787223c. In the point of sale, concurrent sales of the same product can happen, e.g. if several physical points of sales are open at the same time, each with their own session. In the case where the underlying product's valuation is tracked automatically and perpetually, the creation of the pos order leads to the creation of the stock picking, which in turn leads to a search for the next available svl. Because of the flush_all, this can cause lots of retry failures and associated delay/latency/overall perceived slowness for the end user. opw-6206709
This update resolves an issue where new products weren't consistently added to the bottom of sales orders when using the mobile interface. The fix adjusts how product sequences are managed within the system, ensuring that new items are correctly positioned at the end of the order. This improves the user experience for mobile sales order management.
This update fixes a display issue on the website where incorrect stock quantities were shown for product variants that didn't exist. The fix addresses a technical problem related to how stock levels are calculated when a variant is not created, ensuring accurate stock information is presented to customers. This improves the customer experience and prevents overselling.
Original PR description
Issue: --- If a product template has dynamic attributes, some variants might not exist. For those variants, we are showing wrong stock in the website. To reproduce: 1- Create a product with a dynamic attribute and two values. 2- Publish the product and uncheck sell when out-of-stock and check show product when the qty is less than 5. 3- Create a purchase order with qty = 4 for the first value, so a variant is created for it. 4- Go to the website shop. Open the product. 4 available qty in stock is shown for the first variant which is correct. 5- Select 2nd variant. As you see, still 4 available qty is shown which is wrong. As the out-of-stock sale is unchecked, an out-of-stock warning should be shown. Cause and Fix: --- This is due to `isMainProduct` being always False when `product_id` is not set which makes `free_qty` and `out_of_stock` not to be updated. opw-6237602
This update fixes an issue where newly created tasks were incorrectly defaulting to the first project's customer instead of the project selected by the user. The fix ensures that a new task always uses the customer associated with the project it's created within, improving data accuracy and user experience. This change was made to align task customer data with project assignments.
Original PR description
**Problem:** When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.…
**Problem:** When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer. **Steps to reproduce:** 1. Create a new task and select a project that has a customer. 2. The Customer is set to that project's customer. 3. Select another project configured with a different customer. 4. Observe the Customer keeps the first project's customer. **Current behavior:** The Customer keeps the first selected project's customer. **Expected behavior:** The Customer follows the selected project and shows its customer. **Cause of the issue:** partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer. **Fix:** Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes. opw-6315902