Send order receipt email once an order is placed or validated, depending on the workflow used.

Created on 14 July 2017, almost 7 years ago
Updated 12 December 2023, 7 months ago

This is follow-up for #2821909: Send an email when an order is placed

Currently an order receipt email is sent when order is placed (regardless of the order workflow used). On cases when one of the workflows with validation in use, it would be preferred to send out order receipt email once order has validated (instead of placed).

Use case example:
Some of the payment providers uses push notifications to notify that user has completed a purchase. Cases like that use of workflow with validation is preferred way (as guided by Bojanz): Order is placed once user is redirected back to the return url. Order is set to validation state once notification received. Once order is validated, order receipt email should be sent out ...

One approach to resolve this could be as @mglaman already proposed in #commerce support channel:
- In order types admin UI condition added to emails fieldset (Send email when order is: placed/validated)
- A generic State Machine event “Hey! I’m transitioning!” added to State Machine
- In OrderReceiptSubscriber.php the generic event subscribed instead of specific transition event
- Once the generic event fired, the order type’s condition setting would be checked and email would be sent out based on selected condition.

Feature request
Status

Closed: won't fix

Version

2.0

Component

Order

Created by

🇫🇮Finland mitrpaka

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇨🇭Switzerland Mistrae

    Re-roll the path with lastest version (commerce_order_post_update_16 is now used)

  • Status changed to Closed: won't fix 11 months ago
  • 🇮🇱Israel jsacksick

    Some people might want to send the receipt only when the order is paid, and this wouldn't cover this usecase.
    Additionally, the setting mentions the "state", while in reality we're then testing the transition... I don't think this is a good change, all workflows are required to have a "place" transition.

  • 🇺🇸United States gcb

    I'm confused at why this is "won't fix". Allowing the email trigger transition to be configurable seems very reasonable. @jsacksick you say that the patch references "state" where it should reference "transition" and you are right, of course, but are you saying that's the reason you aren't going to accept the patch? Because someone labeled their variables incorrectly? I can fix that if it will maybe change your mind! The functionality is still good IMO.

    I thought Commerce Recurring did use a "place" transition. For whatever reason, it just does that before "paying", and so maybe that should get fixed, but until it does, this would be a really helpful workaround that only makes Commerce more feature-ful. I see you listed as a maintainer on Commerce Recurring, so perhaps you can clarify for us what we are doing wrong with some more actionable feedback?

    I'm attaching a patch that changes only 2 things from the one in 27:

    1. It changes the configuration option label to "transition" rather than "state". (I didn't rename all the variables etc, but if the maintainers would consider committing if I did, I can do that.)
    2. It changes the name of the update hook to be descriptive rather than numeric so you won't have collisions as time goes on. I can't figure why commerce is using numeric post update hook names -- that is a requirement of hook_update_N but not hook_post_update, and that was done on purpose. I'm assuming in part to avoid problems like this! Anyway, the numeric restriction is probably just going to make messes in contributed space like this -- if I use the patch above, I'm likely to miss a future commerce update hook and end up in big trouble.

Production build 0.69.0 2024