I'm not sure if this is the intended behaviour or not.
I have a product doctype with a content picker (e.g. categories) and have selected some nodes and added a quantity to the cart.
I'm viewing this in debug via a custom discount rule provider, I can see that bool type property has an expected value but the value for the content picker appears to be the object's name that is generated by models builder.
Currently the default ProductAdapter just assumes a given property value can be fetched as string as we need to store it in a generic string dictionary which is what the order / order line properties collection is.
Not really sure how we could reconcile this. Could serialize it to JSON, but I don't think that would be that ideal here either. Could possibly look for some TypeConverters or something to be able to convert models to string, or maybe fire some events to allow you to override how it "serializes" a value.
Given you are looking at an array here, what value exactly would you be expecting to see in the properties collection?
I followed the example on creating a custom order discount rule which specified in the object settings, a property with type of Udi.
public class OrderCategoryDiscountRuleProviderSettings
{
[DiscountRuleProviderSetting(Key = "category", Name = "Category", Description = "The category alias", View = "contentPicker", Config = "{startNode:-1, multiPicker:false, idType:'udi'}")]
public Udi Category { get; set; }
}
So I guess I was 'naively' expecting a similar value, but I get that how could it be anticipated what value I would be expecting.
However I've gotten around that issue by injecting IContentService in to my rule provider instance , fetching each product and checking the property manually.
I guess this if this was the assumption, ideally we'd need to potentially pass the raw DB value, rather than a potentially typed value. I'll need to look into that.
I've had a little dig and I think if you really needed to convert it, we should be using some Umbraco logic that does attempt to use TypeConverters so I think you could create a type converter to convert the list to string and then register it globally in an Umbraco component like
TypeDescriptor.AddAttributes(typeof(IEnumerable<Category>), new TypeConverterAttribute(typeof(MyCategoryTypeConverter)));
I haven't tried this, but it should be possible.
Definitely something to think about though, how we pass complex types to the order / order lines properties collection 🤔
Passing the value would remove the need to fetch the content nodes.
However, it was trivial using IContentService. Would it have implications on rule validation?
Say, in this instance i'm using a 'category' node. If a product is updated and the category removed from the product it should logically invalidate the discount for that product. If the value is stored then it would continue to validate.
In 100% of our cases, the client always wanted any cart items to be re-validated immediately when anything changed, e.g. product, prices, discount rules etc.
Removing the category from a product, won't immediately invalidate the discount in an order, it would only update once the order is calculated again (which is usually when something changes on it).
To force it, you'd probably have to try and lookup all unfinalized orders which contain a product belonging to that category and tell them to recalculate, but that could be pretty intensive.
Also, you may want to look into our concept of Price Freezing as once a product is added to the cart, we freeze the price for that product whilst ever there is one of those products in the cart https://vendr.net/docs/core/1-2-0/key-concepts/price-freezing/ From our experience, customers shouldn't really have items in their cart changing value throughout the checkout process if the store owner decides to hike the price up.
If you want to bypass this, then you'll have to hook into the events system to tell it to thaw prices accordingly (details on the link above)
For complex properties such as content picker the value passed to the order line is the type name rather than the content
I'm not sure if this is the intended behaviour or not.
I have a product doctype with a content picker (e.g. categories) and have selected some nodes and added a quantity to the cart.
I'm viewing this in debug via a custom discount rule provider, I can see that bool type property has an expected value but the value for the content picker appears to be the object's name that is generated by models builder.
Currently the default
ProductAdapterjust assumes a given property value can be fetched as string as we need to store it in a generic string dictionary which is what the order / order line properties collection is.Not really sure how we could reconcile this. Could serialize it to JSON, but I don't think that would be that ideal here either. Could possibly look for some TypeConverters or something to be able to convert models to string, or maybe fire some events to allow you to override how it "serializes" a value.
Given you are looking at an array here, what value exactly would you be expecting to see in the properties collection?
I followed the example on creating a custom order discount rule which specified in the object settings, a property with type of Udi.
So I guess I was 'naively' expecting a similar value, but I get that how could it be anticipated what value I would be expecting.
However I've gotten around that issue by injecting IContentService in to my rule provider instance , fetching each product and checking the property manually.
Cool, well I'm glad you've got it working.
I guess this if this was the assumption, ideally we'd need to potentially pass the raw DB value, rather than a potentially typed value. I'll need to look into that.
I've had a little dig and I think if you really needed to convert it, we should be using some Umbraco logic that does attempt to use TypeConverters so I think you could create a type converter to convert the list to string and then register it globally in an Umbraco component like
I haven't tried this, but it should be possible.
Definitely something to think about though, how we pass complex types to the order / order lines properties collection 🤔
Passing the value would remove the need to fetch the content nodes.
However, it was trivial using IContentService. Would it have implications on rule validation?
Say, in this instance i'm using a 'category' node. If a product is updated and the category removed from the product it should logically invalidate the discount for that product. If the value is stored then it would continue to validate.
In 100% of our cases, the client always wanted any cart items to be re-validated immediately when anything changed, e.g. product, prices, discount rules etc.
Ok, well those are some other topics.
Removing the category from a product, won't immediately invalidate the discount in an order, it would only update once the order is calculated again (which is usually when something changes on it).
To force it, you'd probably have to try and lookup all unfinalized orders which contain a product belonging to that category and tell them to recalculate, but that could be pretty intensive.
Also, you may want to look into our concept of Price Freezing as once a product is added to the cart, we freeze the price for that product whilst ever there is one of those products in the cart https://vendr.net/docs/core/1-2-0/key-concepts/price-freezing/ From our experience, customers shouldn't really have items in their cart changing value throughout the checkout process if the store owner decides to hike the price up.
If you want to bypass this, then you'll have to hook into the events system to tell it to thaw prices accordingly (details on the link above)
is working on a reply...