[18.0][MIG] purchase_manual_delivery #2432
Conversation
StefanRijnhart
force-pushed
the
18.0-mig-purchase_manual_delivery
branch
from
2c24f7e to
fa9a5cc
Compare
StefanRijnhart
force-pushed
the
18.0-mig-purchase_manual_delivery
branch
from
3ec0395 to
a65d3fd
Compare
| return super( | ||
| PurchaseOrder, self.with_context(manual_delivery=True) | ||
| ).button_confirm() |
There was a problem hiding this comment.
Doesn't it seem like an obvious bug?
That it should be return self.with_context(manual_delivery=True) ).button_confirm()? Otherwise, you go back to purchase, and skip all overrides defined there. I'm not even sure that there's a good reason for this design (I frankly doubt it), but having all overrides in one case and not the other seems quite dangerous.
There was a problem hiding this comment.
If you mean, we should avoid creating a picking even when button_confirm is called directly in some way, I agree. I suggest we turn the mechanism around and make _create_picking do nothing for POs with manual_delivery=True unless a specific context key is present. We can then pass that context key in the wizard to force creating pickings for manualy delivery POs. Do you agree?
There was a problem hiding this comment.
I agree, that's the part where I suggested that I don't think it's a very good design (if the code of button_confirm_manual was directly put into an override of button_confirm that depends on a context key, you can still have 2 different buttons by putting the context in the attributes).
To make my point clearer, suppose you have module purchase_x that depends on purchase, and that it does an override of button_confirm to call fx.
Because purchase_x and purchase_manual_delivery have no relation to each other, we could either have purchase_manual_delivery => purchase_x => purchase, or purchase_x => purchase_manual_delivery => purchase.
If you call button confirm, in all cases you will call fx once. If you call button_confirm_manual, in one case you will call fx but not the other, depending on how the ORM loaded modules. If you decide that you want an easy solution and add an override of button_confirm_manual to also call fx, then you have the possibility to call fx twice, so you'd better be sure to make it idempotent.
There was a problem hiding this comment.
Ah, I see what you mean and you are right, that is a straightforward bug and can be fixed with
| return super( | |
| PurchaseOrder, self.with_context(manual_delivery=True) | |
| ).button_confirm() | |
| return self.with_context(manual_delivery=True).button_confirm() |
Do you see additional value in the refactoring that I suggested?
There was a problem hiding this comment.
I sure do! Since a migration is the most appropriate time to do it, I will make a PR with the simple fix for 17.0 and give you a review when you're done.
There was a problem hiding this comment.
I can do it, if you like.
There was a problem hiding this comment.
I need to rebase anyway.
There was a problem hiding this comment.
Just ping me when your refactoring is ready for review :-)
17.0 fix: #2573
There was a problem hiding this comment.
Here you go. I also added an additional fix for the fact that stock moves were still created when increasing quantities on order lines of a confirmed (manual delivery) order. Test failures are unrelated and fixed in #2576
[ADD] ability to change destination location in wizard
Currently translated at 100.0% (56 of 56 strings) Translation: purchase-workflow-14.0/purchase-workflow-14.0-purchase_manual_delivery Translate-URL: https://translation.odoo-community.org/projects/purchase-workflow-14-0/purchase-workflow-14-0-purchase_manual_delivery/sl/
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: purchase-workflow-16.0/purchase-workflow-16.0-purchase_manual_delivery Translate-URL: https://translation.odoo-community.org/projects/purchase-workflow-16-0/purchase-workflow-16-0-purchase_manual_delivery/
…utton when manual_delivery is False
Purchase Order Lines that are pending to receive are not considered for stock forecast. Thus, the manual and automatic reordering of products can be done despite having already create a Purchase Order and surpassing the max quantity. Confirmed Purchase Orders with pending to receive Purchase Order Lines are now considered at the forecast and the forecast report.
…' stock moves Rename existing_qty to qty_in_receipt. It now reflects the quantity for which there are pending stock moves and no longer includes the quantities of 'done' stock moves. Co-authored-by: Cas Vissers <[email protected]>
StefanRijnhart
force-pushed
the
18.0-mig-purchase_manual_delivery
branch
2 times, most recently
from
68afb36 to
b8ffd5f
Compare
* Move models and views into their own model file * Integrate with purchase_order_line_menu
StefanRijnhart
force-pushed
the
18.0-mig-purchase_manual_delivery
branch
from
b8ffd5f to
fca6f05
Compare
To prevent interference from other modules. In this case, there is a purchase
order from Odoo's demo data in a confirmed state but without a picking for the
product. The missing picking causes purchase_manual_delivery to include the
PO line's quantity in the forecasted quantity of the product. This prevents
the procurement to go through in TestPurchaseRequestProcurement.test_orderpoint.
```
2024-09-26 14:16:17,327 269 ERROR odoo odoo.addons.purchase_request.tests.test_purchase_request_procurement: FAIL: TestPurchaseRequestProcurement.test_orderpoint
Traceback (most recent call last):
File "/__w/purchase-workflow/purchase-workflow/purchase_request/tests/test_purchase_request_procurement.py", line 81, in test_orderpoint
self.assertEqual(
AssertionError: 0.0 != 5
```
|
This PR has the |
|
/ocabot merge nobump |
|
This PR looks fantastic, let's merge it! |
|
It looks like something changed on |
|
Congratulations, your PR was merged at 5a147e1. Thanks a lot for contributing to OCA. ❤️ |
From unmerged #2417