Skip to content
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

Conversation

fw-bot
Copy link
Contributor

@fw-bot fw-bot commented Mar 22, 2024

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.

Test added in https://github.com/odoo/enterprise/pull/58264

opw-3754297

Forward-Port-Of: #157515

**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
@robodoo
Copy link
Contributor

robodoo commented Mar 22, 2024

@fw-bot
Copy link
Contributor Author

fw-bot commented Mar 22, 2024

@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 @robodoo r+ as they are all considered “in conflict”.

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

@robodoo robodoo added forwardport This PR was created by @fw-bot conflict There was an error while creating this forward-port PR labels Mar 22, 2024
@C3POdoo C3POdoo added the OE the report is linked to a support ticket (opw-...) label Mar 22, 2024
@arj-odoo
Copy link
Contributor

@robodoo r+

@robodoo
Copy link
Contributor

robodoo commented Mar 26, 2024

@arj-odoo you may want to rebuild or fix this PR as it has failed CI.

@robodoo
Copy link
Contributor

robodoo commented Mar 27, 2024

@ethanrobv @arj-odoo linked pull request(s) odoo/enterprise#59301 not ready. Linked PRs are not staged until all of them are ready.

@ethanrobv
Copy link
Contributor

@robodoo retry

@robodoo
Copy link
Contributor

robodoo commented Mar 28, 2024

I'm sorry, @ethanrobv: retry makes no sense when the PR is not in error.

@robodoo robodoo closed this in c6842f1 Mar 28, 2024
@fw-bot fw-bot deleted the 17.0-16.0-opw-3754297-recurring-order-with-option-change-plan-etvi-bSjT-fw branch April 11, 2024 10:46
@ethanrobv ethanrobv restored the 17.0-16.0-opw-3754297-recurring-order-with-option-change-plan-etvi-bSjT-fw branch April 12, 2024 09:04
ethanrobv added a commit to odoo-dev/odoo that referenced this pull request Apr 15, 2024
**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
ethanrobv added a commit to odoo-dev/odoo that referenced this pull request Apr 15, 2024
**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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conflict There was an error while creating this forward-port PR forwardport This PR was created by @fw-bot OE the report is linked to a support ticket (opw-...)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants