Add a booking cancellation lifecycle to the Yoyaku example workflow. A confirmed booking can always be cancelled up to the slot start; a resource refund_deadline policy decides only whether the cancellation is refunded.
What it does
- Resource
refund_deadline(+ unit) field: how long before the slot a cancellation is still refunded. - The confirmation email carries a signed "Cancel booking" link and button; clicking lands on a confirmation screen (with the order summary, and a notice when past the refund deadline) rather than cancelling on arrival, so link prefetching cannot cancel a booking.
- After confirmation the run forks into a cancellation branch and the deposit branch, rejoined by a value-aware (quorum) join: cancelling tears down the deposit branch (voiding any hold), cancels the order, and runs an operator refund review only when a refund is due (a real captured payment, within the deadline), then sends a dedicated "cancelled" notification.
- Customer notifications (confirmed / released / cancelled) all go to the order customer email; the notifier carries the process variables in the event context.
Covered by a kernel test for the schedule resolver and a functional cancel-path test. Docs and French translations updated.
Issue fork yoyaku-3609384
Show commands
Start 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:
Comments
Comment #3
mably commentedImplemented in MR !7. Verified on a live site: cancel before the refund deadline (operator refund review) and after (non-refundable notice, no review); deposit branch torn down on cancel. Kernel + functional tests green.
Comment #5
mably commented