odoo/odoo#164467
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.2-saas-16.4-fix-repair-from-return-abdu-K3L_-fw
- head
- daa3f3e752ab7f6db36946a4d3a7271c662e2c1d
- merged
- 1 year ago by Logistics, Mohammad Abdulmoneim (abdu)
| odoo/odoo | |
|---|---|
| saas-16.4 | #162452 |
| 17.0 | #164385 |
| saas-17.1 | #164464 |
| saas-17.2 | #164467 |
| 18.0 | |
| saas-18.2 | |
| saas-18.3 | |
| saas-18.4 | |
| 19.0 | |
| master | #164470 |
[FW][FIX] repair: repair from return issues
This PR addresses two issues related to creating repair orders from return transfers:
The First issue:
Steps to reproduce the issue:
- Activate is_repairable option on any picking type, let's say "Receipts"
- Create a delivery order with any product(s).
- Validate it.
- Return it.
- Validate the generated receipt transfer.
- From the generated receipt, click on "Repair" button on the top.
- Fill the required fields of the repair order and confirm it.
- Add any part (stock.move) to the repair order.
Expected behavior:
- The new stock.move is created and the availability is determined based on quantities in stock.
Current behavior:
- The created stock.move is not only attached to the repair order, but is also attached to the related return transfer.
- Since the return transfer may be done, no stock move lines are assigned to the newly linked move, which affects the availability making it unavailable.
- This availablity status also affects the repair order making it unable to reserve any quantity for its parts.
The issue is because clicking on "Repair" button from stock.picking form, adds default_picking_id to the context variable to be used on the repair.order form. When creating stock moves from the repair order form, the default_picking_id key in the context is propagated and used to link the new move to a picking, hence, leading to this undesired behavior.
The Second Issue:
Steps to reproduce the issue:
- Create a delivery order.
- Validate it.
- Return it.
- Without navigating to another page, validate the generated receipt order.
- Click on "Repair" button.
- Select any product on the RO form.
Expected behavior:
- Form is saved and the repair order is created.
Current behavior:
- Validation error shows: "A mandatory field is not set", parts_location_id.
The issue is caused by default_picking_type_id key that exists in the context variable when a return order is created from another transfer. This variable propagates to the creation of the repair order and is used instead of the correct picking type which is "Repairs" in that case.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr