Coupons with no granted amount can not be added at checkout [#2045121]

If one creates a new type of coupon (or uses a fixed type coupon with zero value), even if active, when one attempts to add it at checkout, the system appears to accept it (no error is displayed), but nothing happens- that is, it silently fails.

The expected behaviour is that the coupon code should appear in the table as normal, with a 'Granted amount' value of 0.

In defence of 'why create a coupon with zero value': this is not as pointless as it may seem. Our business logic rules check against an additional field that might be enabled on the coupon, which make available discounted delivery options if a coupon with this field is attached to the order- so even though there's no discount immediately at the start of the checkout process (i.e. none of the products are discounted), there coupon is still providing a discount to the shopper at a later stage.

Comments

Comment #1

pcambra

he/him

Spanish

Asturies

CreditAttribution: pcambra commented 18 July 2013 at 18:00

Version:	7.x-1.0-beta7	» 7.x-1.x-dev
Category:	bug	» feature

Could you try the dev version? some changes have been included there #1986204: Coupons marked as "inactive" do not display error/invalid message when applied to an order

that is, it silently fails

How can you tell that it fails?, it will probably not add a null coupon to the order, which it doesn't necessarily means it's failing.

I don't see a generic value of adding such a feature to the module, seems to me a particular workflow for the use case you're facing but I'm open to include patches to control this behavior.

Comment #2

ajpgarner CreditAttribution: ajpgarner commented 18 July 2013 at 22:31

By 'fails', in this context, I mean the coupon does not appear in the checkout pane, nor is it associated with the order if one probes it (e.g. using commerce_coupon_action_get_coupons_for_order at a later stage).

I think in this context, I'm treating coupon in a very generic sense of customer-entered code that can be attached to an order; rather than explicitly as a discount. In the current design of the module, it would appear that the discounting is handled by rules anyway (i.e. the coupons will discount the order in the appropriate for the coupon type)- so for the system to reject the attachment of a coupon because it has zero discount value (even though it has other fields attached which affect the order) seems like enforcing a particular business logic in the code.

However, I will concede my usage is a little esoteric, so I am happy to look into this myself, and see if I can come up with a sensible patch.