Hi,

If you're looking for a quick fix you could use the Group.Name or Group.Description properties to store your value or char separated values. It's a bit of a hack and will not be very self explanatory in the UI, but if you're populating the data by integration from another system it might be ok.

Another possible solution would be to create a custom BlockData type with all the properties you need, impelement a custom editor and add a collection of the BlockData type on your content type. 

I would consider this a feature request. Many types of associations between catalog content needs extra properties, epi should seriously consider making the associations IContent.

Use cases that comes from top of my head

- "Replaced By..." could possible need quantity when for example a 5 litres container has been replaced by 1 litre containers.

- Spare/service parts for a product might need several properties, for example qty showing how many you need for your specific product, placement to identify which one is correct for you (front, rear, outer, inner etc)

Hi,

I do agree that Association should be able to extended - but I don't think it should be IContent.

Can you provide more information of how do you want it to be extended? What kind of data you want to add and what do you use them for? While I can't promise it will happen any time soon, I will make sure we'll take a look at it and consider options.

Regards,

/Q

Thanks Mattias and Quan!

Mattias: I suspected a "dirty" solution was the way to go. Now I can proceed without the anxiety that there exist a pretty way of doing this that i'm not aware of :)

Quan: I have product variants that are related to one ore more service variants. The same service can be enabled/disabled and eligible/not eligible for a specific product. Thats why the information ideally should live on the association, not on the source or target.

Regards

Gustav

I agree with Mattias, properties on associations would be really usefull. You often want to set a quantity and/or type of association.

The ones you mentioned - type and quantity - are supported by default, at least in DTO way. The quantity is not reflected in content way as we don't see the need for that.

/Q

Hi Quan,

We' try to stay away from the dto apis as much as we can :)

Looking into the db neither CatalogAssociation not CatalogEntryAssociation have a qty field. How is that data stored? Are you mixing it up with CatalogRelation which is used by package and bundle entries? Or is there a third table for the associations where the qty is stored?

Yeah, My bad - I've been mixing up between association with relation. Should have had a coffee before writing anything :)

However, why would you want to have a quantity for association? Any use cases for that? (We're looking for realworld use cases if we are to implement something)

Regards,

/Q

One use case from a previous client was showing service parts for example for printers.
To service printer A we need 1 qty of spare part B. But for printer C we would need 2 qty of spare part B.

Another use case is replacements or alternative products.

Let's say we're selling oil. The 5 litres container is out of stock, but we have an alternative association for 5 qty of 1 litre containers.

Or the 100 pack of condoms is discontinued and replaced by a 10 pack, and we wish to show the replacement product and the qty needed to fulfill the qty of the replaced product :)

The use case refered to by Gustav in this thread - we have a subscription which contains a set of services that we wish to visualize. Some of the services are default for one subscription but not for the other. Some services are available for one subscription, some are not - but we need to visualize both available and unavailable. Since the services are not configurable by the buyer for a subscription it should not be treated as a package or a configurable.

Thanks for your input - we'll surely look into how to improve association in future releases.

/Q