* if a product has a option it cannot be oversold

* Improve error message

---------

Co-authored-by: wessel <wessel@highbiza.nl>
Co-authored-by: Lars van de Kerkhof <lars@permanentmarkers.nl>

* Implemented predefined product options

* css

* added missing migration in the test app

* Added tests

* added test

* added test

* Added more testz

* Added validation

* Renamed add_optional_choice to add_empty_choice

* added release notes

* Added help_text help text.

yup

* Use a JSONField for the option value

* removed pylint

* fix display of multi and checkbox in basket and order (#13)

* fix display of multi and checkbox in basket and order

Co-authored-by: willeke huizing <38961397+willekeh@users.noreply.github.com>

Revert changes in #1913 and #2294 that required a stock record to have price_excl_tax set in order to report the product as available.

Add separate checks to the basket form/add logic that checks at the time of
adding a product to the basket whether a price exists, and report an error if it doesn't.

Fixes #2664.

As in `test_model.py` -> `test_models.py`

Better to use filenames which are commonly used in the python word then
custom ones.

And this is the outer-most frame of the Yak-shave: preventing the many
errors messages I get from the public sandbox site where people try to
add products of multiple currencies to their basket.

It was quite a journey...

This shows the problem with forms knowing too much of the details of
collaborators. This is a design smell and will be looked at before
things get too stinky.

This is quite a large change. It:

- Alters the add-to-basket URL to have the "base" product's PK in it
- Changes the constructor of the AddToBasket form to not require
  purchase_info (even though I only just introduced it!)
- Renames the product_id field to variant_id and only uses it for group
  products

These changes are motivated by the variant workflow. Before this change,
you effectively had different forms being used for rending and
validation as the product being passed to the form constructor was the
group product when rendering but the variant when validating. This just
about worked but was not nice.

The purchase_info param is removed as we can only calculate the
purchase_info once the variant product has been validated. Hence we
again violate Demeter and make a deep call to the purchase info
calculation within the basket form. Might revisit this again.

This change also simplifies the basket view logic and allows a form to
be removed.

This means we don't need to do the law-of-demeter-violating call to
fetch the purchase info for a product (line 79 of forms.py). HOWEVER,
I'm starting to have second thoughts about this - I've discovered that
the adding to basket process is quite confusing for variants and I
intend to refactor.

This commit also adds some useful tests though so it's a valid stepping
stone to a better place.

Plus some comments on why things are the way they are in the form.