[Phil]

Aleksey,

I know that a few people have expressed interest in being able to generate many coupon codes for promotions and the like. I had to do something similar to hand out unique coupon codes to individuals. I looked in to what would have to be done to duplicate an existing coupon code and decided it would be too much, so I took a different approach. I created a module that "translates" the coupon code requests. I create a record with each unique code indicating which "master" coupon it's linked to and run every request to set a coupon code through a custom handler that turns unique coupon codes into the master one (and back again before displaying it).

I was wondering if something similar might be useful to do natively - basically allow you to create aliases for a coupon code so that one discount rule could be linked to many coupon codes, which I think is what most individuals are looking for. The amount of time I've given to considering this leads me to believe that such a table would be fairly simple so creating new aliases for existing coupons should be quite simple, as opposed to the work required to duplicate an entire rule.

Anyway, just some food for thought and perhaps you've already considered this and there are other things I've missed :)

Cheers,

Phil

[Aleksey]

Hi, Phil!

That's a good idea. I added a link to your post in the Roadmap task #1274.

Thank you!

[fetopher]

Second request for this. Groupon is interested in our products and this type of solution would be ideal.

[Phil]

Aleksey,

I know you've added this to your roadmap, but if we could have a couple events added as an interim solution that would make a world of difference. I'm currently developing a module that handles this sort of situation (many codes mapped to one internal discount), but right now the way I'm filtering the coupon codes from the front-end is a little convoluted. If you could add two events/hooks to the following, that would be fantastic:

beforeCouponCodeSet: this hook would allow you to filter the coupon code going before it hits the system's internal checks, so you can see if it exists in the alias table and set the expected internal code.
beforeCouponCodeDisplayed: this hook would do the reverse of the previous hook, allowing you to filter an internal code just before it's displayed.

Right now I'm having to extend Shop_Actions with a custom action to handle the filter going in, and having to add my reverse filter within the template itself, which feels way too much like a hack to me.

Thanks!

Phil

[Aleksey]

Hi, Phil!

Sure, we can do it. To save our time, can you please tell me which exactly places of LemonStand code the events should be triggered? You can post the hacked code snippets here, and I will check them and add to our codebase.

Thank you

[Phil]

Hi Aleksey,

Sorry it took me so long to get back to you. Here's where I was thinking it would be nice to have something:

In shop_actions.php

public function on_setCouponCode($allow_redirect = true)
{
	$coupon_code = trim(post('coupon'));
	if ($changed_code = Backend::$events->fireEvent('shop:onBeforeSetCouponCode', $coupon_code)) 
		$coupon_code = $changed_code;
	if (strlen($coupon_code))
	{
		$coupon = Shop_Coupon::find_coupon($coupon_code);
		if (!$coupon)
			throw new Cms_Exception('A coupon with the specified code is not found');
	}
		
	Shop_CheckoutData::set_coupon_code($coupon_code);
	
	$redirect = post('redirect');
	if ($allow_redirect && $redirect)
		Phpr::$response->redirect($redirect);
}

In shop_checkoutdata.php

public static function get_coupon_code()
{
	$checkout_data = self::load();

	if (!array_key_exists('coupon_code', $checkout_data))
		return null;
		
	$coupon_code = $checkout_data['coupon_code'];
	if ($changed_code = Backend::$events->fireEvent('shop:onBeforeDisplayCouponCode', $coupon_code))
		$coupon_code = $changed_code;
	return $coupon_code;
}

The problem with the second function is that it's used for both displaying the code to the front-end user and internally for some discount-related calls, so I think a wrapper function should actually be added, but you get the idea.

Overall I think this should handle most of the needs - the if ($changed_code ... ) clause could be a little better defined - perhaps sometimes if a certain code is entered on the front end a user would want to return false to prevent the coupon from going through, but otherwise would return null to just indicate that they aren't changing the code. I'm not sure how best to handle that in regards to the Lemonstand internal event structure.

Hopefully this gives you a good idea of where I'm hoping this can go, though!

Thanks,

Phil

[Aleksey]

Hi guys, we just published the new API events.

Thank you