-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(): added compute actions for buyget promotions #6255
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Ignored Deployments
|
b6655a6
to
ae1a999
Compare
product_category: { | ||
id: "catg_cotton", | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought(non-blocking): would probably change this shape to be product_categories: [{...}]
We should do this in a different API but let's add a task to settle on the final shape of the inputs to the promotion module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it works both ways already. You can pass product_categories: [] or product_category: {}. We've only added very few definition restrictions here.
Let me know if thats not what you meant
allocation: "each", | ||
max_quantity: 1, | ||
apply_to_quantity: 1, | ||
buy_rules_min_quantity: 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: would want this to be part of the buy_rules instead. e.g., { attribute: "quantity", operator: "gt", values: 1 }
. All buy rules would then be evaluated with an AND
operator on for each item. Wdyt of this idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this might be quite limiting when we want to expand cases. It would only allow one BuyRule for item targeting and will also result in some relationship validations as min_qty is a required field.
I think there are 2 cases here:
- each rule needs to conform to a grouped quantity
ex: buy a cotton shirt and a silk shirt and get a sweater for free
or
ex: buy 2 cotton shirt and get a sweater for free
In this case, we need to use an OR operator.
buy_rules_type: "across",
buy_rules_min_quantity: 2,
buy_rules: [{
attribute: "product_category.id",
operator: "eq",
values: ["catg_cotton"],
}, {
attribute: "product_category.id",
operator: "eq",
values: ["catg_silk"],
}],
- each rule conforms to its own min_quantity
ex: buy 2 cotton tshirts and 1 silk shirt and get a sweater free.
In this case, we need to use an AND operator.
buy_rules_type: "each",
buy_rules_min_quantity: null,
buy_rules: [{
attribute: "product_category.id",
operator: "eq",
values: ["catg_cotton"],
min_quantity: 2
}, {
attribute: "product_category.id",
operator: "eq",
values: ["catg_silk"],
min_quantity: 1
}],
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense! Kinda hard to wrap your head around, but it makes sense - would be amazing if this could self-document somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently only case 1 is implemented. When implementing case 2, I can rework the code to make it more easily readable with some inline comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
what: