Promotion action to create store credits

[stem]

Hi,

@epicery, we wanted to create promotion which would give cash back to our customers on order completion.

To do that, we simply hacked into the order's state machine and call #perform_at_completion on all promotion actions which implement it.

With that in place, our need is a really simple PromotionAction which implement only the new method and create a store credit.

Would you be interested in a PR with that functionality?
I could extract it from our codebase, and make some documentation around it.

[kennyadsl]

@stem I like the idea. I think it's a good practice to also add a promotion action that does something similar in core, rather than adding support for this in an abstract way. This way, we will be able to add tests for this behavior and be sure we don't break the functionality with time.

In terms of implementation, and not sure it's a good idea, have you considered creating a new association between promotions and actions called has_many :completion_actions or something similar, so we don't need to add a new method in the action but we can create specific actions with this purpose (or maybe also use current one)?

[stem]

Hey.

We went with the least resistant path and did not think about a new relationship 😀
I can of course provide a new action which create store credit as I already have that!

For the final implementation, I think we should have 2 ways of defining actions based on when they are execute. Creating a SC for a cart seems a bad idea and not reusing the Spree::PromotionAction#perform is a good way to explicitly tell that this action is performed at cart or completion phase.
I can think of 2 different ways :

• another method name (like we did)
• another base class (but I can't think of a good name)

What do you think ?

[kennyadsl]

I'm looking at the PromotionHandler and I think it can be a life-saver here. It's just a matter of adding a new promotion handler code side at the order completion and add a new activator here in the promotion new/edit page to specify that the promotion needs do things after the order is completed.

To me, it looks like the less invasive solution but please, feel free to point out if I'm missing something.

[stem]

I might not have a proper grasp on the big picture, but I don't think the activation will help us.

Let me describe what we use this for, and you can point me in the right direction if I'm wrong somewhere.

We have 2 distinct use cases :

1. a referral program : the promotion has 2 rules (first order and a custom user is referred) and 2 actions (create an order adjustment of 10 € for the new customer and create a 10 € store credit for the referring user)

2. a more "classic" case : buy more than 100 €, get 5 € off now, and 5 € off on your next order.

now == adjustment
next order == store credits

In both examples, it seems clear to me that we can't activate the promotion (and thus perform all the actions) before the order completion nor we can delay it until the completion.
If it's activated with a coupon or a cart handler (before order completion), the customer will have both the adjustment AND the store credits applied on this order. Or even worse, he can create multiple carts with this promotion applied, let them in the void, and have many store credits for a new and real order! 💸
If it's activated with a new handler (after order completion), the customer will not see the adjustment when paying and will be asked for more than needed! 😕

Once again, I might not have completely understand this part of the promotion system, but I'm quite sure that we need 2 different times to call Action#perform, depending on the action itself, to avoid some weird "race conditions" as I described above and I don't think that the current system can do that, even with a new handler.

That's why we poked inside the state machine and added another method in the PromotionAction interface, but we can also use the STI already in place to have 2 types of actions : performed at activation / performed at completion and the handlers will perform them accordingly.

All that being said, we might indeed create another handler, not list it in the activation method but automatically run it at the order completion so that any activated promotions is handled a second time. That way, we have 2 different performing times, but everything is run through a handler which keeps the responsibility to run the proper actions at the proper time
What do you think ?

Last but not least, I really don't think of another use case except the one we're discussing : creating store credit for someone (mostly the current customer though 😅) so in the end, it might not be a good addition to core. Let me know if we should aim at core or a new extension.

[kennyadsl]

@stem now everything is clear. Thanks for taking the time to explain in detail what you need, it seems interesting to have a basic referral logic support in core. Just wondering if people are also doing other things when the referred user completes the purchase (like maybe sending emails?). In this case, they'd need to hack the promotion system to add this extra logic and it's not ideal. Or maybe a store just gives store credits without any discount for the user and maybe it makes no sense to create a promotion at all in that case.

Let me document a little bit and I'll come back to you with my thoughts.

[kennyadsl]

@stem we discussed this in the last core team meeting and we decided to avoid this feature in core. Despite the scenario seems interesting we think that it's not that common (never needed to anyone in the core team) and if it's needed, it's quite easy to develop this in the store directly.

I think that this customization is perfect for an "advanced" blog post to share how easy it is to make this kind of change to Solidus. Or maybe we could add a paragraph here: https://edgeguides.solidus.io/advanced-solidus/promotions-system ? cc @aldesantis

[kennyadsl]

Moving this to Discussion instead of closing, so we don't lose track of this idea.

[ikbenben1976]

@stem We have the identical referral use case that you described (give 10 get 10). Did you implement a clever solution that you would be willing to share?