Daily updates from Odoo
Monday, April 7, 2025
6 changes · 18.0
New functionality added to Odoo
This adds visibility of product external IDs in product lists and product forms, and allows users to search products by those IDs. It helps teams import related data such as bills of materials and inventory updates without first exporting products to discover system-generated references.
Original PR description
# Description of the issue/feature this PR addresses: Our organization would like to manage the external ID of products (i.e. during product CSV upload) because this lets us later upload BoMs and inventory adjustments that reference this external ID. This avoid an extra step of first finding products in Odoo, downloading them to get their auto-generated external ID, and then re-uploading. # Current behavior before PR: External ID is hidden from the user # Desired behavior after PR is merged: 1. External ID is present on the product list page 2. External ID can be used for searching products 3. External ID is present on the General Information tab of the product form page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents loyalty points from being granted to other open point-of-sale orders when only one order is finalized. It ensures customers receive rewards only for orders that have actually been completed and paid, avoiding incorrect loyalty balances.
Original PR description
Recently, we've face an issue when multiple orders were opened. When one of them was paid, loyalty points were applied for all other opened orders. A fix has been applied to correct the situation:…
Recently, we've face an issue when multiple orders were opened. When one of them was paid, loyalty points were applied for all other opened orders. A fix has been applied to correct the situation: https://github.com/odoo/odoo/commit/2dcad5f32693471588bbe605601d3346b14196be Afterward it appears that the fix does not get rid of the problem 100% of the time. When there are more than 1 order on the payment screen with payment lines covering the total amount, and when one of them is finalized, the other orders are also getting points applied. Why the fix: ------------ The fix mentionned above uses `is_paid()` as a filter to select which orders should get points applied. It seems like `is_paid` is intended to be used to know if the payment lines cover the order amount before the order is truly finalized. https://github.com/odoo/odoo/blob/8be96595ce5795df25b9b7dbea14a0f8c75a804c/addons/point_of_sale/static/src/app/models/pos_order.js#L905-L911 We change the condition to be based on the state of the order instead. opw-4677541
This fixes an error that blocked confirming refund-style sales orders for service products linked to projects. Negative quantity order lines are now treated as refunds and do not try to create project tasks, restoring expected refund behavior.
Original PR description
Steps to reproduce: - Install sale, project apps - Create a service product that creates a task in a project - Create a quotation with this product and order line qty < 0 - Confirm the quotation to a sales order A traceback is thrown stating that the product lacks a project to create a task in. In previous versions, negative qty sales orders were allowed as refunds, but no task was created for them. The issue is in `_timesheet_service_generation`, where -ve qty is treated as if no project is set for the product. This is incorrect since refunds should be allowed for service products. This fix ensures that negative qty sales orders function as refunds without triggering task creation. opw-4669488 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
Bulk document actions that create journal entries now return users to the journal list instead of opening only the last created entry. This makes processing multiple documents at once more predictable and avoids extra navigation for accounting users.
Original PR description
When you apply a journal entry action (e.g. Create Vendor Bill) to several documents at once, you should be redirected to the journal list view. Since version 18.0, you're redirected to the form view of the last entry you've just created. The corresponding actions have several sub-actions and cannot be launched on several records at the same time. The selected documents are processed individually and the last sub-action returns systematically a form view. To fix this, we inject a context key containing the ids of the selection.Then the last sub-action uses it to determine the appropriate view(s) to return. task-4606751
This fixes a manufacturing planning issue where component demand could be missed when the finished product and its component used different unit rounding precision. Planning now uses the more precise rounding, helping ensure required components are correctly forecast and replenished.
Original PR description
When the parent product has a less precise rounding than its component, the indirect demand may sometimes be bypassed because float_compare will round one value to zero and compare it to zero, making them equal. Steps: - create product FINAL, UoM rounding at 1.0 - create product COMPONENT, different UoM with rounding at 0.01 - create a BoM for 16 units of FINAL, with COMPONENT at 0.4 on bom line - create MPS record for FINAL with its new BoM - set the safety stock of MPS FINAL at 10 and its minimum to replenish at 16 Issue: The indirect demand of MPS COMPONENT is not computed because float_compare will round (0.025*16) to zero and compare it with 0, thus bypassing the creation of indirect demand. Fix: Always use the more precise rounding between a product and its component. opw-4654955
Closing a subscription no longer removes previously earned MRR-based commission from the report. This prevents cancellation records from incorrectly offsetting commissions for subscriptions that were already invoiced.
Original PR description
To reproduce ============ 1- create commission plan based on MRR 2- create subscription and invoice it 3- go to the commission report for that plan, the commission for that subs is there 4- close the subscription and check the report again -> the commission is not there anymore even that the sub is invoiced Problem ======= when closing a subscription we create a `sale_order_log` with `amount_signed` equals to negative value of the original sale order, these logs are taken into account in the commission report Solution ======== exclude `sale_order_line` with `event_type == 2_churn` from commission report opw-4650466