Hello,
Thanks to #2223171: Accommodate free orders when no payment methods are enabled for an order we can now easily accommodate free orders in Commerce. This includes orders that become free when a 100% off coupon is used.
However when a coupon of this type is applied to an order, the value shows up in the checkout pane as "1.00% off order" rather than 100%. Attached is a patch which fixes this for order discounts, and I'm not sure if this is the best way to do it, honestly. I know there is another area of the module for product discounts where it does the same thing here:
$rate = $offer_wrapper->commerce_percentage->value();
if ($rate < 1) {
$rate = $rate * 100;
}
$offer_text = $rate . '%';
This doesn't make much sense now, because the rate can actually be 1 if we want to offer a 100% discount. I suggest that we ensure the rate entered into the coupon code's discount field is no greater than 1 at the time of entry, rather than when the coupon is applied. This should normalize the workflow a bit more as well.
Attached is a patch which fixes this displayed output for orders.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | commerce_coupon-fixed_discount_label-2346143-18.patch | 1.08 KB | torgospizza |
Comments
Comment #1
torgospizzaLooks like there may be a larger issue here as well... when attempting to check out with a 100% off discount (via a coupon) I got a DatabaseTransactionOutOfOrder error. It is reproducible and happens with Coupons but not Gift Cards (with commerce_gc). I'll continue to dig and post that as a separate Issue.
Comment #2
dpolant commentedAny further info on this? I could not reproduce with a clean commerce 1.10 site + coupons.
Comment #3
bc commentedplease disregard - commented on wrong tab.
Comment #4
torgospizzaJust bumping this again as my comment from #1 seems to have been unrelated.
When using 1.00 (for a 100% off discount coupon) the display in Checkout panes is incorrect. It shows "1.00% off [product name]" instead of "100%..."
This will also help with #2339719: Clarify / rename the "free products" discount offer type since "Free products" that are not add-on bonuses should not use that offer type, but use a % off product offer instead. Since we'll be pointing store admins to use a 100% off discount for this purpose, we should make sure that the discount shows correctly at checkout.
Patch attached.
Comment #5
mglamanLooks good and proper. I'd like to see a test for this, though. To ensure 100% discount can work. I'll let maintainers decide to mark CNR for this or commit.
Comment #6
torgospizzaCreated a patch with a new test for 100% off product discounts here: #2608788: Patch: test a 100% off product discount
Comment #7
joelpittetCan someone confirm this is inline with the approach in discount for this issue? #2468159: Percentage based discounts : validation needs to be elsewhere
This one looks to be taking the value as x * 100 and the other issue is going to x / 100. I think x / 100 seems to be a better approach.
Comment #8
torgospizzaWell, the discrepancy is due to the fact that the patch in #2468159: Percentage based discounts : validation needs to be elsewhere assumes that the "percentage" entered into the Discounts field is a whole number, which AFAIK is not what the module currently asks for. Has that changed? Right now for a "15 percent off discount" I have to enter "0.15" into the amount off field. With that patch, it would change to just "15". Which I'm totally okay with, but I'm fairly certain this issue would then still exist because 100 / 100 = 1 and I would then get "1.00% off" for a 100% off discount.
Further, the patch there is fixing the validation in the function commerce_discount_percentage() whereas mine is editing commerce_coupon_commerce_coupon_discount_value_display_alter().
If the patch in #2468159: Percentage based discounts : validation needs to be elsewhere gets committed, this patch would then change to this:
Because that code still exists in the display_alter hooks, which the other patch is not concerned with.
Hope this clears things up a bit! I'll admit it's confusing.
Comment #9
michfuer commentedI think this issue highlights what appears to be a fairly convoluted way to calculate the percentage discount as well as generate its label. IMO since the form element for Percentage has a % suffix in the discount UI I would expect that entering 90 would create a 90% discount, and entering 0.5 would create a 0.5% discount.
That's not the case currently. If I enter 100 I get a 100% discount. If I enter 0.5 I get a 50% discount. From the latest -dev of commerce_discount the calculation in commerce_discount_percentage() uses the following to set $rate
and then later on $rate is multiplied by price values to calculate the discount. We can get rid of that and just do
$rate = $discount_wrapper->commerce_discount_offer->commerce_percentage->value()/100;This gets us the correct discount value, but not label. Right now in commerce_coupon_commerce_coupon_discount_value_display_alter() the label is being created with
Again, we could just remove the $rate changing condition and get the correct label. I was thinking I'd try for the commerce_discount update first, and than re-visit this with a patch. Feedback is appreciated.
Comment #10
torgospizzaGood catch, @michfuer. I think your approach sounds like the optimal way to go - everything should really be standardized and/or abstracted more. I'd be interested and seeing and testing your patch.
Comment #11
michfuer commentedOk, so commerce_discount has been updated to calculate the discount $rate as discussed in #9. This patch should fix its display.
Comment #12
joelpittetThank you:) Less silliness.
Comment #13
torgospizzaLooks good but there are two places where this occurs in that display_alter() function, under product_discount as well as order_discount. Looks like this patch only took care of one of them.
Comment #14
joelpittetNice catch, should have looked closer.
Comment #15
torgospizzaHere is a re-roll with both places. We're using this patch in production and it is indeed much nicer.
Comment #16
joelpittetQuick question while we are at it:
Maybe it's worth providing better context to the translators? t('@percentage% off order', array('@percentage' => ...))
Comment #17
torgospizzaMakes sense. How's this?
Comment #18
torgospizzaWhoops, did it wrong. Try this instead.
Comment #19
mglamanSo clean. So fresh.
Comment #20
torgospizzaWhy are the tests green with 0 passes? Is testBot okay?
Comment #22
mglamanOh duh. Because there's no tests, just applies tests. I wrote initial tests here #2614392: Add tests! Start with basic UI tests..
Comment #23
torgospizzaHa! That makes sense. I thought for sure we already had tests, but hey, learn something new every day.
Thanks all! I'm glad this finally got fixed a year after I initially reported it :)
Comment #24
mglamanCommitted!