Prevent adding child products to products with stock records
The implicit conversion of a standalone product to a child product only
works if certain conditions are met. As far as I can tell, the only
condition preventing a conversion would be when the product already has
stock records -- parent products aren't allowed to have any.
Beef up ProductCreateView to handle creating child products
A third way to use the view has been added: when called with a parent's
primary key, the view now handles the creation of child products. It
passes the parent into the context, so that both when creating and
editing child products, the template can hide most of the fields.
Implicit product structure: Handle creating and deleting
This is the easy bit. Product structure defaults to standalone product
when creating a product, and reverts to standalone product when the last
child product is deleted.
For the sake of a good UX, product structure handling will be hidden
away from the user. Instead, the following behaviour will be implemented:
* A newly created product defaults to being a standalone product.
* Child products can only be created from the variants section of an
existing product. When that happens, the existing products becomes a
parent product.
* When the last child product is deleted, the parent product is marked
as a standalone product again.
Note that this implicit behaviour will be reserved to Oscar's dashboard
views, because it purely exists for a good UX. It will be easy to
override to ensure that more advanced scenarios are still possible.
This change simplifies the logic that is needed in ProductForm, which is
implemented in this commit. Product structure is kept as a hidden field
to ease ajax'fied dashboard editing.
Note that prior to this commit, ProductForm set the product class on
child products even though child products inherit their product class
from their parent. The old get_product_class method would also return
the wrong product class.
Filter product update template by product structure
Several sections are not applicable for products of a certain structure.
Hence, they're naively hidden by hiding them in the navigation.
No further hiding is done to ease customisation of what gets shown, to
reduce redundancy and to reduce the chance of the nav and the actual
section display logic getting out of sync.
It's recommended to view this commit with the ignore-whitespace option.
The product delete view doesn't use get_title() for the child products.
Hence it potentially shows empty titles. Showing identical titles is at
least slightly less confusing.
It also uses get_title for the title of the deleted product, because one
might use the view to delete a child product.
* Product status has been removed as field, and hence can be removed as a
column.
* The list now doesn't list child products individually. This suits the
anticipated workflow much better, and better shows how child products
are dependant on their parents.
* Parent products can't have stockrecords, so show a minus instead of 0.
* Standalone products can't have children, so show a minus instead of 0.
Remove Python 2 requirements from requirements_demo.txt
They were added in 02a13da, but I can't find an explanation for why they
were added. AFAIK, the demo site builds fine without them. Oscar doesn't
depend on them directly, and any dependencies should pull them in
automatically. Furthermore, BeautifulSoup 3 is not compatible with
Python 3.
Use updated datacash extension for Django 1.7 support
django-oscar-datacash 0.8.1 caused the demo site build process to fail;
thus failing the Travis test suite for Django 1.7. The newly released
version should fix this issue and ensure that tests pass for Django
1.7.
* Use SILENCED_SYSTEM_CHECKS warning instead of test runner hack to
avoid the warning about a change in default test runners
* Conditionally use south in the demo settings
* Add native migrations and app configs for forked apps
I missed that RC2 was released three days ago. I now follow
@djangoproject so that doesn't happen again.
The release candidate is a much saner target to test against, so let's
do that.
This means that custom deployments can reuse Oscar's test factories,
even if they're running different models.
This commit was triggered by the StockRecordFactory. The datacash
factory relied on it, but installed Oscar as a dependency and hence the
custom StockRecord model used in Oscar's test suite was not available.
They are both used in oscar.test, which means it's "public Oscar API".
Deployments might rely on e.g. the factories for their own test suite,
so all needed dependencies need to be installed as part of Oscar.
factory-boy 2.4 brings some nice, but breaking API changes.
The missing dependencies were discovered when working on
django-oscar-datacash, where some of the old-style factories are used,
but newfactories gets imported into that namespace.
Document further changes necessary when upgrading Django
The main issue is that Oscar relies on it's app configs to keep class
loading working. Hence, appropriate app configs need to be created when
upgrading.
A custom app needs to inherit from Oscar's app config. This ensures the
correct app label, and that any startup code (receivers, etc.) is
executed.
Per the camp ground rule, the fork_app command has been slightly
refactored.
get_model: Raise LookupError instead of ImportError
oscar.core.loading.get_model is a thin wrapper around Django 1.6's
get_model function. The latter returns None if the model can't be found,
whereas the Oscar variant loudly failed with an ImportError.
With Django's app refactor, most of that behaviour in Django has been
changed, and Oscar's get_model falls back to Django's
get_registered_model. But the latter raises a LookupError.
To avoid having to catch both errors, Oscar's get_model now raises a
LookupError no matter what Django version is used. This should have
minimal impact on backwards compatibility, as get_model isn't really
used outside of Oscar core.
Both the master branch and Django 1.7 branch introduced a South
migration for offers. It's been addressed by dropping the one introduced
on the Django 1.7 branch, and re-creating it.
The native migrations have been completely recreated.
Motivated by 51bf7280, this change adds a new make target to find parts
of the codebase that need changing after some event has happened. It
also adds an example TODO.
To create test databases, the Django test runner calls the 'migrate'
management command, and I think the current Nose test runner calls
'syncdb', which under Django 1.7 is aliased to 'migrate'.
This command inspects the migration graph to figure out the migrations
to run. So it inspects the migrations that ship with Oscar. Some of them
depend on the partner or customer migrations. The test suite swaps out
those apps. Until now, the command then couldn't find the initial
migrations and would fail with a dependency error.
As far as I can tell, there's no good way to just call what used to be
"syncdb" and ignore migrations completely. So for now, we will have to
create migrations for the test apps that replace Oscar.
Enhance tests/config.py to ease using the configured environment
It can sometimes be useful to be able to drop into the configured Django
environment of the test suite. It might e.g. be useful to drop into the
shell with ./config.py shell_plus or create missing migrations with
./config.py makemigrations
I needed this to create migrations for the test suite apps.
Different Django 1.7 commit to avoid migration issue
Django 1.7 still suffers from a range of migration problems. This one
caused migrations to be created infinitely:
https://code.djangoproject.com/ticket/23014
A commit prior to that change, but containing the fix for #23041, fixes
the issue for now.
I don't know how I missed them. I think I must've made a mistake while
heavily rebasing this branch; it's the second time I'm surprised to not
find certain changes I'm confident I did.
Maik Hoepfel
Ziyad Soobhan
Markus Bertheau
andysellick
David Winterbottom
Bonza-Times