[15.0][FIX] purchase_request: do not close allocations on locked orders - #3167
[15.0][FIX] purchase_request: do not close allocations on locked orders#3167les-adhoc wants to merge 1 commit into
Conversation
_compute_open_product_qty treats a purchase order line in state done as a finished purchase and zeroes the open quantity. In Odoo that state means "Locked", a modification lock, not a completion: receipts still happen afterwards, and core creates and processes them for locked orders (_create_picking accepts both purchase and done). With po_lock = 'lock' the order reaches done at approval time, so the allocation is closed before any receipt can happen. As a consequence stock.move.line.allocate() never allocates the incoming quantity, the requester is never notified of the receipt, qty_done and qty_in_progress stay at 0 on the request line, and stock.move.copy_data carries no allocation over to backorders. Nothing fails and nothing is logged. This is a regression: the same one line change was requested by a maintainer in OCA#1419 and merged into 14.0 by OCA#1422, but the forward port to 15.0 brought back the version including done, and 15.0 up to 18.0 still carry it. cancel is the only state that really means nothing else will be allocated: once a receipt completes, allocated_product_qty reaches requested_product_uom_qty and the open quantity becomes 0 on its own. Add a test covering the locked order flow, which no test exercised because po_lock defaults to edit.
489f6ef to
34b34c0
Compare
|
/ocabot merge patch |
|
@HviorForgeFlow The merge process could not start, because command |
|
/ocabot merge patch |
|
This PR looks fantastic, let's merge it! |
|
@HviorForgeFlow your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-3167-by-HviorForgeFlow-bump-patch. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
|
/ocabot merge patch |
|
Hey, thanks for contributing! Proceeding to merge this for you. |
|
@HviorForgeFlow your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-3167-by-HviorForgeFlow-bump-patch. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
|
/ocabot merge patch |
|
Hey, thanks for contributing! Proceeding to merge this for you. |
|
@HviorForgeFlow your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-3167-by-HviorForgeFlow-bump-patch. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
4 participants
Fix forwarded from 18.0 to 15.0
Original pull request (18.0): #3160
doneon a purchase order means "Locked", a modification lock, not acompletion, so a locked order must not close the allocation. See the original
PR for the full analysis and the regression history (#1419, #1422).
The test is adapted to 15.0:
qty_doneon the move line, andmail.mt_commentas the subtype, since the dedicated
mt_request_picking_donesubtype onlyexists from 16.0 on.