odoo/odoo#173306
Created by fw-bot
Statuses:
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/template: Contact runbot team on discord for help.
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- label
- odoo-dev:saas-17.4-17.0-opw-3942297-repair-avoid-traceback-with-kit-otd-MvY8-fw
- head
- b3f2ea9177db620901ed20979e0c00a36a0941ea
- merged
- 7 months ago by Bugfix, Djamel Touati (otd)
| odoo/odoo | |
|---|---|
| 17.0 | #168227 |
| saas-17.1 | #170331 |
| saas-17.2 | #170352 |
| saas-17.3 | #170628 |
| saas-17.4 | #173306 |
| 18.0 | #184798 |
| saas-18.1 | |
| saas-18.2 | |
| saas-18.3 | |
| master | #184802 |
[FW][FIX] repair: allow the repair of consumable kit products
Steps to reproduce the bug:
- Create a consumable product “Kit 1” with the following BoM:
- component: X1
- Create a repair order to repair one unit of Kit 1:
- Don’t add any part
- confirm and Start the repair
- try to end the repair
Problem:
A traceback is triggered:
“raise ValueError("Expected singleton: %s" % self)
Value Error: Expected singleton: stock.location()
“
When the "action_repair_end" is called, a move is created with the kit
product, and then we attempt to confirm it:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L80
Since the product is a kit, it is exploded into two moves with products
“X1” and “X2”. We then try to assign them a “repair” picking_type_id:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L74
So, the write method is used and since the “picking_type_id” is in the
vals, and the product in the move (X1) is not the same as the one in the
repair order, we consider this product a “Part” of the repair.
Therefore, we try to use its location_id and location_dest_id, which we
fetch based on the “repair_line_type” that will be False because it is
not a part of the repair but rather the product to be repaired:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L93-L94
The first error is triggered during the “should_by_pass” check because
there is no location set in the move:
https://github.com/odoo/odoo/blob/c7b947364d34cc6ccfb1eb7a2c16b6bba226d8e7/addons/stock/models/stock_move.py#L1051-L1052
If we fix this error, we will still encounter an error because both
moves will be confirmed. However, we will return to the first loop to
continue calling the “_trigger_scheduler” function for the first move
with the “Kit” product, which will be already deleted because it was
exploded, resulting in a user error:
“odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: stock.move(253,), User: 1)
“
opw-3942297