I suppose it isn't wrong that this module is attempting to describe in long form the parameters of a coupon, but I believe it's not the best approach for two reasons:

  1. This module simple can't know how to describe all of the available conditions, especially if a discount rule is updated manually to include additional conditions that this module would never know about. For those sites that use a limited, known set of discount conditions, they could opt into this long form format for describing the parameters by editing the order coupons View and choosing that field handler.
  2. The bigger concern is usability, though: we lose the direct association between the discount applied via the coupon and its price component in the order total. Granted, if someone wants to figure it out, they can (so long as the long form is correct), but why make the customer think any harder about whether or not they were fairly granted their discount?

Fortunately, the Commerce Discount module already has a component_title property for discounts that is designed to be the name of the discount as displayed to customers. The order coupons View should be updated with the appropriate relationship and use of that field instead of the one that is currently used.

Comments

rszrama created an issue.

Frederic wbase’s picture

Any update about this issue?

dpolant’s picture

Agreed - I've never really liked the original approach I took for this. I think it would be good to simplify that views field handler and have it just use the discount title. We probably don't even need a custom handler any more, just a relationship to the discount offer.

Frederic wbase’s picture

I've already tried a lot of things with relationships and then i get duplicate issues. I would love to help with this issue. Maybe we can devide the work load for this? Where to start?

jddeli’s picture

I will like to see the possibility to do that?
If there is a solution it will be good for this module.