Deprecate AbstractOption

[john-parton]

There was some discussion in #1756 to deprecate AbstractOption in favor of AbstractAttributeOption.

There does seem to be some overlap and it's somewhat confusing when you would want to use one more than the other.

I also have an open PR to add a MULTI_OPTION type. #1740

[sk1ll10]

We are currently developing a shop for personalized products and are planning to make heavy use of the AbstractOption functionality as this seems to be it's intended use case. I am still working my way into the oscar concepts so if i got this wrong never mind. Suggestions to continue in a better way are very welcome!

[john-parton]

At the very least, I think there needs to be better documentation for when one might want to use an AbstractOption vs an AbstractAttributeOption. The similarity in the names makes it quite confusing.

[sasha0]

Since MULTI_OPTION attribute type is merged, we can think about possibility of switching from product option to attribute option. From my perspective, we can refactor basket form and models to show attribute options as choices and similar to existing approach, store selected option in the AbstractLineAttribute model. Any thoughts @mvantellingen @solarissmoke ?

[solarissmoke]

Since MULTI_OPTION attribute type is merged, we can think about possibility of switching from product option to attribute option.

No, I disagree. Attributes and options are two different things and they need to be kept separate.

Attributes are simply structured product information - a way to store information about products in a way that allows you to search/filter based on them. For example, a laptop might have a disk_space attribute where you can store how big the hard disk is. This allows you to search/filter based on that as well as display this information in a structured way to the customer.

Options are specific purchase choices that are selected when a customer makes a purchase. e.g., they might be able to select a certain image to be printed on their T-shirt, or select a specific colour for their laptop.

The MULTI_OPTION attribute doesn't help here - it is still an attribute, not a purchase option. For example, a laptop could have a output_type attribute that allows multiple values (multi option) like HDMI, and VGA. A laptop can support both. These are just features of the laptop, not options for purchase.

There are some cases where options and attributes look very similar (e.g., the colour of a T-shirt) but these are special cases. For that reason we need to keep them separate.

I think the issue here is just one of naming. Maybe we can rename Option if it is not clear how it is different from AttributeOption.

[sasha0]

How about the case when we need not to fill in option (e.g. example case - SMS text), but select option from choices? E.g. if MULTI_OPTION stores attribute options (available colors or sizes for instance) and customer can select one.

[solarissmoke]

How about the case when we need to select option from choices?

Then those need to be stored as Options on the product. In cases where attributes are identical to options, you could auto-generate the Options based on the attributes, but this would be up to the implementor. From Oscar's perspective attributes are a generic way to store any information about a product.

[sasha0]

Would you create a PR with your intelligible explanation of the topic based on the comment above? 😉