Shouldn't the default value for max_uses and max_uses_per_user be 1 rather than 0 (= unlimited)?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | uc_coupon.patch | 875 bytes | killes@www.drop.org |
Shouldn't the default value for max_uses and max_uses_per_user be 1 rather than 0 (= unlimited)?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | uc_coupon.patch | 875 bytes | killes@www.drop.org |
Comments
Comment #1
longwaveWhy? I think either 0 or 1 are valid defaults, depending on the intended use of the coupon (use by several users or just one user) and 0 is the way it's always been since I inherited the module, so unless there's a compelling reason to change to 1 I think I will leave this alone.
Comment #2
killes@www.drop.org commentedDo you think that "create coupons that are valid multiple times" is a useful default? I wouldn't want these in my store. Maybe my situation is a bit special: We sell the coupons at a fair and people can later redeem them on the website.
Anyway, here's a patch to change it to 1, which I believe is more sensible.
Comment #3
longwaveA common use case I have seen is where coupons are basically used as affiliate tracking codes, a multi-use coupon is created for each site that links to the store, and customers are encouraged to use the code to get 5% or 10% off each order.
I also think that keeping the default as 0 makes more sense when you think that coupons are not restricted by product, user, role, taxonomy, class, etc. by default - the general default for coupons is to be as unrestricted as possible, the store admin selects the necessary restrictions when first setting them up. It would be less intuitive to me that coupons are restricted by usage count by default but not by any other restriction method.
As I can see arguments for both sides here, perhaps this should be configured on a separate module-wide configuration page instead? Although that's pretty much overkill for what is actually needed here!
Comment #4
killes@www.drop.org commentedThe problem is that if you actually want to have a coupon with unlimited redemptions, a coupon that you accidentally created with only one redemption is an annoyance.
If you actually only want to have a single redemption and accidentally create a coupon with unlimited redemptions you potentially lose a lof of money...
If you want to make this configurable, I'll create a patch for that.
Comment #5
longwaveYou could argue the same if you misconfigure the coupon in any other way, you could lose a lot of money if you fail to add any other necessary restrictions; user error is not necessarily a problem you can solve technically.
As I can still see an advantage to having the default set both ways, I think making a site-wide configuration option to select the default for new coupons will work best.
Comment #6
killes@www.drop.org commentedwhere do you want the configuration option to appear?
Comment #7
longwaveI guess a "Coupon settings" screen at /admin/store/settings/coupon would work to be consistent with other Ubercart store wide settings. with a radio button selection for defaulting to "Single use" or "Multi use" coupons.
The current placement of the other coupon menu items underneath "Customers" isn't ideal - otherwise I would suggest a "Settings" tab to be added there - but that's another issue!
Comment #8
longwaveFixed in HEAD by taking the simplest option of removing the default value entirely, now you must enter 0 or 1 or whatever is necessary for both max uses fields when creating a new coupon.
Comment #9
john franklin commentedI would expect the common use case for one-use coupons to be creating a whole stack of unique one-use coupons, a task covered by the bulk coupon creation tool. If you are creating a single coupon, that would be in most use cases a multi-use coupon.
Comment #11
longwaveHaving to manually enter the default for every new coupon is annoying me already, so I added the config option.