New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FW][FIX] sale_management: dispense temp cache records #158950
[FW][FIX] sale_management: dispense temp cache records #158950
Conversation
**Current behavior:** If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs. **Expected behavior:** The recurring plan can be changed as it ordinarily would. **Steps to reproduce:** 1. Add a recurring product to a sale order 2. Add an optional recurring product to the order 3. Try to change the recurring plan of the order to encounter the trace back **Cause of the issue:** This flow causes some 'phantom' sale order lines to have their price recalculated (phantom because they have no price, qty, currency, nor order_id field values). During this recalculation a currency_id is expected either in the line itself or in the sale order it is a part of. Because there is no value for either of these, it fails the ensure_one() method in the sequence (0 vals, expects 1). The phantom lines are created in the `sale.order.option` model in the `sale_management` module, in `_compute_price_unit()` and `_compute_discount()`. **Fix:** Call `invalidate_recorset(flush=False)` on these cached records at the end of the methods in which they are created. opw-3754297 X-original-commit: 16f51c9
@ethanrobv while this was properly forward-ported, at least one co-dependent PR (odoo/enterprise#59301) did not succeed. You will need to fix it before this can be merged. Both this PR and the others will need to be approved via More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
@robodoo r+ |
@arj-odoo you may want to rebuild or fix this PR as it has failed CI. |
@ethanrobv @arj-odoo linked pull request(s) odoo/enterprise#59301 not ready. Linked PRs are not staged until all of them are ready. |
@robodoo retry |
I'm sorry, @ethanrobv: retry makes no sense when the PR is not in error. |
**Current behavior:** Creating a subscription order and adding an order line and order option before setting the recurrence plan will result in an empty order line being added to the order. (All fields null/empty/false) **Expected behavior:** Setting the recurrence plan will not create a new order line. **Steps to reproduce:** 1. Create a subscription order 2. Add an recurring product as an order line and an optional recurring product 3. Give the order a recurring plan 4. Observe the new empty order line **Cause of the issue:** When processing the onchange methods which depend on `plan_id`, we will call `_compute_price_unit()` and _compute_discount()` in `sale_management : sale.order.option`, where we create some temp records to perform the respective computations. These temporary records are not being sufficiently invalidated. Prior to odoo#158950 we "dispensed" these temp records by setting their `order_id` to False- this issue still occurs even using that method of exclusion. **Fix:** Fetch the `order_line` to ensure we have an up-to-date reference. This PR fixes the test added by: odoo/enterprise@64685cd which broke in the 17.0 fw-port: odoo/enterprise@ab3cf34 opw-3754297
**Current behavior:** Creating a subscription order and adding an order line and order option before setting the recurrence plan will result in an empty order line being added to the order. (All fields null/empty/false) **Expected behavior:** Setting the recurrence plan will not create a new order line. **Steps to reproduce:** 1. Create a subscription order 2. Add an recurring product as an order line and an optional recurring product 3. Give the order a recurring plan 4. Observe the new empty order line **Cause of the issue:** When processing the onchange methods which depend on `plan_id`, we will call `_compute_price_unit()` and _compute_discount()` in `sale_management : sale.order.option`, where we create some temp records to perform the respective computations. These temporary records are not being sufficiently invalidated. Prior to odoo#158950 we "dispensed" these temp records by setting their `order_id` to False- this issue still occurs even using that method of exclusion. **Fix:** Fetch the `order_line` to ensure we have an up-to-date reference. This PR fixes the test added by: odoo/enterprise@64685cd which broke in the 17.0 fw-port: odoo/enterprise@ab3cf34 opw-3754297
Current behavior:
If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs.
Expected behavior:
The recurring plan can be changed as it ordinarily would.
Steps to reproduce:
Add a recurring product to a sale order
Add an optional recurring product to the order
Try to change the recurring plan of the order to encounter the trace back
Cause of the issue:
This flow causes some 'phantom' sale order lines to have their price recalculated (phantom because they have no price, qty, currency, nor order_id field values). During this recalculation a currency_id is expected either in the line itself or in the sale order it is a part of. Because there is no value for either of these, it fails the ensure_one() method in the sequence (0 vals, expects 1).
The phantom lines are created in the
sale.order.option
model in thesale_management
module, in_compute_price_unit()
and_compute_discount()
.Fix:
Call
invalidate_recorset(flush=False)
on these cached records at the end of the methods in which they are created.Test added in https://github.com/odoo/enterprise/pull/58264
opw-3754297
Forward-Port-Of: #157515