Why the Coupon entity has expiresAt property , when a promotion is expired , a coupon based on this promotion is also expired, even though the coupon expiration is longer than the promotion , it confuses me for a long time.
bump - I would also be interested to know more about this field. it doesn't make much sense for me.
A coupon can expire before the corresponding promotion does. Or the promotion might not expire at all, but the corresponding coupons do.
@sblaut , thanks for sharing your point, if so , I think we need to limit coupon expiration date not longer than the promotion it is based.
@sblaut I see what you mean, but still, for me, it doesn't make much sense.
a campaign having two different batches of coupons with different expiry date seems like we're talking about two different campaigns.
but maybe that's just me :)
@gabiudrescu I understand your logic, this feature seems redundant. To simplify logic and reduce confusion I think we will remove expiresAt from Coupon and perhaps bring it back when we find a real use case for that.
/cc @pamil
Aaaah no 😠— we were heavily using this function. The use case is that you don't use the expiry date on the promotion (it's not set, so no expiry date), and you create coupons that have one. With this, you can assign coupons of the same promotion to different users at different times.
Let's say you have a "free mug" offer — you buy a product and then you get a coupon, valid for a month, that entitles you to a free mug or whatever other product.
Before it was easy : a single "free mug" promotion, and when the customer bought a product you would create a coupon of this promotion, expire it at now+1month and send it to the customer. Boom, done.
Now, with your PR, you have to create a promotion for each customer (!!!) with a single coupon. This is really overkill and a bad practice. Can you add it back ? Please ? This is definitely not redundant
I agree. This is not redundant at all. It is perfectly reasonable to have coupons with different expiration dates in the same promotion. We are using this as well.
And, I must add, leaving this property here is not really bothering anyone even if you don't use it. It's not a security threat either, and it doesn't affect the quality of code, or the size of the code base in a substantial manner...
So I guess that we could leave this property and take care of more important features.
@tchapi thank you for the feedback. Your use case is of course reasonable so we decided to leave the exiresAt property on Coupon 😉
That's great — and that's a good opportunity for me to thank you for taking care of your community this way. I'm really happy to develop solutions on top of the Sylius app, so even though we sometimes get mad at you for breaking stuff, in the end I think we can agree that we're excited to be part of the community here, and Sylius is definitely a good step forward in the realm of e-commerce solutions !
I think this can be closed :)
Most helpful comment
That's great — and that's a good opportunity for me to thank you for taking care of your community this way. I'm really happy to develop solutions on top of the Sylius app, so even though we sometimes get mad at you for breaking stuff, in the end I think we can agree that we're excited to be part of the community here, and Sylius is definitely a good step forward in the realm of e-commerce solutions !