The example workflow locked the order with an n_lock action when the flow entered the payment step, and unlocked it with n_unlock on Back. That locks the order too early, on the payment landing page before the payer commits to paying, and makes the lock a workflow concern rather than a payment one.
Drive it from the payment round-trip instead. A new OrderLockSubscriber in yoyaku_payment locks the order on kessai.initiated (the payer deliberate handoff to the provider) and unlocks it back to the editable basket on a failed or cancelled payment. It runs whether or not the event is handled, since the order lock is orthogonal to who resumes the workflow, and acts only on the checkout payment whose subject is the order.
The example workflow drops n_lock and n_unlock: the payment-required route goes straight to the payment step, its Back goes straight to the form, and n_place still places the order on both the paid and free branches. The LockOrder and UnlockOrder action plugins stay, so a custom workflow can still use them.
Depends on the kessai handoff event (kessai #3611852); orchestra side is #3611855. Covered by the end to end workflow test.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
mably commentedOpened merge request !47 against 1.x.
OrderLockSubscriberlocks the order onkessai.initiatedand unlocks on failure or cancellation; the example workflow dropsn_lockandn_unlock(keptn_placeon both branches and the action plugins). The full end to end suite passes locally (10 tests). Depends on the kessai handoff event (kessai #3611852), so CI here goes green once that has landed in kessai 1.x-dev.Comment #5
mably commented