Oscar already has child products to model tightly coupled products, and
"recommended products" to model products that are related (which we
expect to mostly be used for upselling). Product.related_products was a
third option that sat somewhere inbetween, and which I think will often
not be needed, has a mediocre interface in the dashboard and beyond that
no special treatment in the codebase. Furthermore, I see it being
confusing when trying to model a catalogue, and it's easily added back
if necessary.
Conceptually, save() is the wrong place for model validation. ModelForms
call clean() before saving, so the results should be the same as long as
they are used.
Fixes #1297.
On my local machine, django-dynamic-fixture created product classes
where the slug and primary key were identical and the tests passed
although the check was wrong. Luckily, Murphy's Law works in our favour
on Travis CI, and that failed and spotted it.
This commit fixes the assumption that the redirect view expects the slug
(which it doesn't since the last commit), and ensures that the generated
product classes are non-numeric.
This should greatly increase usability of the dashboard product update
page when managing a large amount of products.
Fixes #618
Conflicts:
oscar/apps/dashboard/catalogue/forms.py
oscar/apps/dashboard/catalogue/views.py
oscar/static/oscar/js/oscar/dashboard.js
oscar/views/generic.py
Widgets for product selection using select2 and ajax
Prior to this change, it was possible to select child products in the
product dashboard. A new function get_parent_products_queryset was
introduced, analogues to the existing get_related_products_queryset. It
is not based on the BrowsableManager as I can envision scenarios where
that is extended to respect status fields or such like, which we should
ignore when selecting a parent field. Otherwise it wouldn't be possible
to e.g. add a few hidden products with child products.
Two issues in tests with the G library were fixed as well, were
unintentionally child products were created. If the product field is
left unspecified, it seems to pick a product instead of leaving it as
None.
This allows updating code in both places, if necessary. Getting Django
1.5 support would be painful otherwise. This also removes the circular
dependency of django-oscar-testsupport on Oscar.
The requirements were merged. The imports were updated
accordingly. Unused imports in the touched files were removed. No
further changes.
The previous UPC validation in ``ProductForm`` broke updating the
a product. I realised this while digging around to fix the broken
``StockRecord`` issue that broke the CI build.
The validation now uses Django's validation of ``unique`` fields
instead and works.
The ``StockRecord`` issue was related to creating a form in the
update view providing stock record data in POST with ``partner``
empty. I corrected that and added a test case for it.
Attempting to create a new product with a UPC that already exists
raises an ``IntegrityError`` instead of handling the ``ProductForm``
as an invalid form with an appropriate ``ValidationError``.
I fixed that by adding a ``clean_upc`` validation method to the
form by checking for an existing product by UPC. I am not sure if
that is the most efficient way to validate this. If there's a
better alternative, I am happy to change it...and learn something
:)
**Note:** I switched the functional tests in ``product_tests.py``
to use ``WebTest`` while I was at it.