Allow contrib to alter coupon availability check

Created on 23 September 2018, almost 6 years ago
Updated 4 July 2024, 2 months ago

Problem/Motivation

In short:
public function available(OrderInterface $order)
is responsible to aknowledge if a coupon is available or not, but it's decisionnal process can't be altered by contrib modules.

For instance, if a contrib wants to define an "Expire Date" per coupon. Currently, it has no way to check that extra parameter when a coupon is classified as "available" or not by available() method.

Proposed resolution

Proposed solution is to call a hook_coupon_aavailable method which returns a boolean
hook_coupon_available(OrderInterface order, CouponInterface coupon)

If proposition is accepted as an implementation strategy, I can try providing a draft patch.

Remaining tasks

- Define implementation strategy
- Create patch

User interface changes

None

API changes

Add a hook method

Data model changes

None

Feature request
Status

Closed: won't fix

Version

2.0

Component

Promotions

Created by

🇫🇷France Dom.

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇳🇴Norway zaporylie

    I stumbled upon this issue when researching the ability to limit coupon usage to specific user (order owner). The business case is - send 10% off unique coupon code to the user upon their birthday. Coupon is only valid for 1 month and can only be redeemed by the same user who received the coupon. Other users, authenticated or anonymous, can't use that particular coupon (but they may have their own coupons).

    For the performance reason promotion per user is not sustainable. All that's left is the ability to connect coupon with specific user and limit the availability.

  • 🇩🇪Germany mkalkbrenner 🇩🇪

    We have this requirement, too.
    In our B2B use-case, multiple registered users belong to the same "customers". So we need to summarize the redemptions of all users of the same "customer". That could easily be done by altering the result of the available() function.
    I suggest to introduce an event here.

  • Status changed to Closed: won't fix 2 months ago
  • 🇮🇱Israel jsacksick

    I agree with Matt here, let's not bloat coupons... The promotion is where you're supposed to set the conditions. Adding an event might seem harmless, but guessing this still has a performance footprint...
    Additionally, if you're comfortable writing an event subscriber... Then swapping the coupon entity class and overridding the available() method isn't much different.

  • Status changed to Needs work 2 months ago
  • 🇩🇪Germany mkalkbrenner 🇩🇪

    Additionally, if you're comfortable writing an event subscriber... Then swapping the coupon entity class and overridding the available() method isn't much different.

    We did it like that ... first.
    Now we found a much easier solution by swapping the PromotionUsage service against a class that overwrites load().

    The only issue is that it is not an API and it takes time to read the code to find a solution.

  • Status changed to Closed: won't fix 2 months ago
Production build 0.71.5 2024