What does the JSON for the discount rules look like in the database. It looks like it's having a problem deserializing it, with the group MatchType coming back as null 🤔
Ok, so the null reference bug is purely because of lack of selection there (maybe a mandatory field? or some catch there?)
The main issue is related only with the "Group" rule. Any other methods works there.
We've found recently that in Umbraco IMember, the cast object has null value in Member's properties. Any chance that you're using this property to validate if member is in role or has the role(s) described in the rules??
Good catch on the Match Type, we'll see what can be done about making fields mandatory. At the very least, it should have a default value such that this error doesn't display.
Regarding the discount applying, the order first of all needs to be assigned to a member as it's from the orders customer reference that we test the rule against, not the member that is currently in session.
By default Vendr should try to assign the customer at 2 stages. 1 when the order is created (there is a bug on this one which will be fixed in 1.3.4, the next patch release) and 2 just before the order is about to go to the payment screen. Outside of this you'll need to call order.AssignToCustomer() to manually assign the order to a customer. It's quite possible that the customer may not have been logged in at the point of creating the order, but later logs in. If that is the case, you need to call this method as unfortunately, there is no universal way for us to know when a session becomes authenticated / unauthenticated.
My guess then is that the order isn't assigned to the logged in customer and so the discount isn't applying.
Indeed, associating the order with the member solved this issue. The order now knows that the member is logged in and the discount is allowed for the group the member is associated with.
Discount errors
Hi Matt
So we have tried to implement a discount and add a rule that only allows it got be used by a particular member group.
When we try and use it on the front end though we get an error.
![enter image description here][1]
![enter image description here][2]
We are using Vendr v1.3.3 and your checkout package as well.
Any ideas why this might be happening?
Cheers
Hey Adam.
What does the JSON for the discount rules look like in the database. It looks like it's having a problem deserializing it, with the group
MatchTypecoming back as null 🤔Matt
Hey Matt!
That's what's inside the rule Adam created:
And that's the reward JSON:
From what I can see the matchType is null what looks like a source of the problem?
Hiya, sorry I have added the match type now to say 'all' and the error has gone, but the discount is not being applied.
It is is saying it is attached, but not discount is being deducted.
Ok, so the null reference bug is purely because of lack of selection there (maybe a mandatory field? or some catch there?)
The main issue is related only with the "Group" rule. Any other methods works there.
We've found recently that in Umbraco IMember, the cast object has null value in Member's properties. Any chance that you're using this property to validate if member is in role or has the role(s) described in the rules??
Good catch on the Match Type, we'll see what can be done about making fields mandatory. At the very least, it should have a default value such that this error doesn't display.
Regarding the discount applying, the order first of all needs to be assigned to a member as it's from the orders customer reference that we test the rule against, not the member that is currently in session.
By default Vendr should try to assign the customer at 2 stages. 1 when the order is created (there is a bug on this one which will be fixed in 1.3.4, the next patch release) and 2 just before the order is about to go to the payment screen. Outside of this you'll need to call
order.AssignToCustomer()to manually assign the order to a customer. It's quite possible that the customer may not have been logged in at the point of creating the order, but later logs in. If that is the case, you need to call this method as unfortunately, there is no universal way for us to know when a session becomes authenticated / unauthenticated.My guess then is that the order isn't assigned to the logged in customer and so the discount isn't applying.
Matt
Indeed, associating the order with the member solved this issue. The order now knows that the member is logged in and the discount is allowed for the group the member is associated with.
is working on a reply...