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] stock: prevent opening SM when picking is dirty #162721

Closed

Conversation

fw-bot
Copy link
Contributor

@fw-bot fw-bot commented Apr 19, 2024

Steps to reproduce

  • Create two new storable products tracked by USN
  • Create a new RFQ with one of the created product
  • Confirm the order
  • Open the receipt
  • Add a new line with the other product
  • Click on the open move button in the new line
  • Add a new SN
  • Save & close

=> Cannot read properties of undefined (reading 'resId')

Cause of the issue

When calling openRecord, if the record is dirty, it is saved before proceeding.

After saving, we call super.openRecord with the old record. Since that record is no longer linked to the root record (the stock.picking), when we try to save it, it won't match an existing id.

Solution

If the record is new, we don't save as there would be no way of knowing which of the returned line would come from this one.

If we are opening an existing record, we find the new datapoint by matching it's ID.

opw-3777615

Forward-Port-Of: #162645
Forward-Port-Of: #162425

@robodoo robodoo added the forwardport This PR was created by @fw-bot label Apr 19, 2024
@robodoo
Copy link
Contributor

robodoo commented Apr 19, 2024

@fw-bot
Copy link
Contributor Author

fw-bot commented Apr 19, 2024

@hubvd @Whenrow this PR targets master and is the last of the forward-port chain.

To merge the full chain, use

@fw-bot r+

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

@C3POdoo C3POdoo added the OE the report is linked to a support ticket (opw-...) label Apr 19, 2024
@fw-bot
Copy link
Contributor Author

fw-bot commented Apr 19, 2024

@hubvd @Whenrow ci/runbot failed on this forward-port PR

Steps to reproduce
==================

- Create two new storable products tracked by USN
- Create a new RFQ with one of the created product
- Confirm the order
- Open the receipt
- Add a new line with the other product
- Click on the open move button in the new line
- Add a new SN
- Save & close

=> Cannot read properties of undefined (reading 'resId')

Cause of the issue
==================

When calling openRecord, if the record is dirty, it is saved before
proceeding.

After saving, we call super.openRecord with the old record.
Since that record is no longer linked to the root record (the
stock.picking), when we try to save it, it won't match an existing id.

Solution
========

If the record is new, we don't save as there would be no way of knowing
which of the returned line would come from this one.

If we are opening an existing record, we find the new datapoint by
matching it's ID.

opw-3777615

X-original-commit: 127e735
@hubvd hubvd force-pushed the master-17.0-opw-3777615-huvw-1ijx-fw branch from c2fe49c to 950e293 Compare April 22, 2024 06:45
@fw-bot
Copy link
Contributor Author

fw-bot commented Apr 22, 2024

@hubvd @Whenrow this PR was modified / updated and has become a normal PR. It should be merged the normal way (via @robodoo)

@hubvd
Copy link
Contributor

hubvd commented Apr 22, 2024

@robodoo r+

robodoo pushed a commit that referenced this pull request Apr 22, 2024
Steps to reproduce
==================

- Create two new storable products tracked by USN
- Create a new RFQ with one of the created product
- Confirm the order
- Open the receipt
- Add a new line with the other product
- Click on the open move button in the new line
- Add a new SN
- Save & close

=> Cannot read properties of undefined (reading 'resId')

Cause of the issue
==================

When calling openRecord, if the record is dirty, it is saved before
proceeding.

After saving, we call super.openRecord with the old record.
Since that record is no longer linked to the root record (the
stock.picking), when we try to save it, it won't match an existing id.

Solution
========

If the record is new, we don't save as there would be no way of knowing
which of the returned line would come from this one.

If we are opening an existing record, we find the new datapoint by
matching it's ID.

opw-3777615

closes #162721

X-original-commit: 127e735
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
@robodoo robodoo closed this Apr 22, 2024
@robodoo robodoo added the 17.3 label Apr 22, 2024
@hubvd hubvd deleted the master-17.0-opw-3777615-huvw-1ijx-fw branch April 22, 2024 18:40
zel-odoo pushed a commit to odoo-dev/odoo that referenced this pull request Apr 29, 2024
Steps to reproduce
==================

- Create two new storable products tracked by USN
- Create a new RFQ with one of the created product
- Confirm the order
- Open the receipt
- Add a new line with the other product
- Click on the open move button in the new line
- Add a new SN
- Save & close

=> Cannot read properties of undefined (reading 'resId')

Cause of the issue
==================

When calling openRecord, if the record is dirty, it is saved before
proceeding.

After saving, we call super.openRecord with the old record.
Since that record is no longer linked to the root record (the
stock.picking), when we try to save it, it won't match an existing id.

Solution
========

If the record is new, we don't save as there would be no way of knowing
which of the returned line would come from this one.

If we are opening an existing record, we find the new datapoint by
matching it's ID.

opw-3777615

closes odoo#162721

X-original-commit: 127e735
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
17.3 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

4 participants