Monday, April 7, 2025
6 changes
1 change
Resolved issues and error corrections
Shared Field Service tasks linked to sales order lines now open correctly for portal users. This prevents customers or external users from getting stuck when accessing shared task details, while keeping access limited to the specific internal data needed.
Original PR description
Steps to reproduce: - Install Field Service - Share a project that has tasks with sol. - Open task with portal user in portal Issue: - No error and task doesn't open. Reason: - Due to changes in field value getting in the python framework. PR: https://github.com/odoo/odoo/pull/201565 - In this PR the changes are that when ever a field is read/fetched then access is checked even record is cached. Fix: - Add sudo when reading that field because not every task can have this so giving read access is not that good. task-4690463
5 changes
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