Use template egg loader when running the test suite
We wrongly had django-tables2 in the requirements.txt; it was removed
from 4af10d9. This means it was now only installed as an egg. As the
test suite relies on a template from tables2, the test suite
consequently was failing.
Adding the egg loader to the test suite config fixes the problem.
06c2441 changed the way actions are submitted for on the dashboard's
order list view. This commit updates the test to match the new
behaviour.
I'd also argue that the two test methods test different aspects of the
same thing, so I merged them, which saves us one (relatively slow) test
run.
When adding a migration on master, I discovered that the new-style
migrations were strongly out of sync; Django wanted to create new
migrations for almost every app. That was surprising given that no model
changes were made since building that set of migrations.
The issue is that they were built with Django 1.7 RC2, and we've since
switchted to RC3. If I'd have to guess, I'd say the following issue is
responsible for it:
2da20379c0
As beta 1 is only a day old and it doesn't cause major headaches, it was
decided that it's easiest to release a new set of migrations. And pray
to the gods of Python that we won't have a similar situation again
before the Django migrations framework stabilises.
Parent/child products aren't supported in permission-based dashboard
Currently, a product's stockrecords are used to decide if a user is
allowed to edit a product or not. That doesn't work for parent products,
because they don't have stockrecords. So it's not possible to decide
whether a user is allowed to edit a parent product (and e.g. create
children) for it.
As far as I'm aware, this is not a regression of the
permission-dashboard; I don't think it ever worked. It just hasn't been
spotted because nobody needed it.
This commit also adds some tests to ensure this is enforced.
The ProductCreateUpdateView had untested logic to handle invalid parent
products. Unfortunately, it didn't work; the check returned a redirect,
which later was tried to access like a product.
The only place to issue a redirect for invalid products is the dispatch
method, so an altered check has been moved there.
This time with tests...
This already worked only within site offers by way of default model
ordering. Site offers are probably the most common offers, however the
ordering of all offers has to be controlled by the applicator.
Conflicts:
tests/integration/offer/applicator_tests.py
Cherry-picked from #1414.
Don't create objects in the database unless necessary
Conflicts:
oscar/apps/offer/models.py
tests/integration/offer/combination_tests.py
tests/integration/offer/percentage_benefit_tests.py
@maikhoepfel duplicated the proxy class short-circuit logic for
Conditions as part of this commit.
Cherry-picked from #1414.
It was broken without anyone noticing, as reported in #1451. My work in
PR #1441 magically fixed it, but we should still test it.
Fixes #1451.
Also sneakily fixes the wrong URL in the release notes for the previous
commit.
Streamline Benefit and Condition name and description handling
This commit was triggered by a recursion problem mentioned here:
8199da2100 (commitcomment-7387486)
It now unifies handling for name and description across both conditions
and benefits:
* Declaring a name property is required for any proxy class. A few
classes had a description declared, but no name. But given that the
description is the more verbose version, and is allowed to include
HTML, it makes sense to still require a name. The declared
descriptions in the models that only had one property are better
suited for @name anyway.
* It drops the max_unaffected_items logic for Benefits. That was only
applied if calling via the non-proxy class, and feels more like it
should be a description anyway.
* __str__ always returns self.name. Anything more complex with that
means we might run into problems with the python_2_unicode_compatible
decorator.
I also added tests for the changes, and verified the tests fail without
my changes.
This fixes two issues:
1) The code didn't take into account that self.format will be ignored by
Django if USE_L10N=True, unless a format was specified when constructing
the Widget. Remedied by moving the code to render because the current
language is determined at request time, not at object construction time,
and looking up the correct format there.
2) The code couldn't handle date formats that include dots, like
31.12.2014.
Fixes #1440.
Update handling of child product for product ranges
This commit addresses issue #1253.
Currently, the offers app doesn't really consider child products;
behaviour is undefined. This commit addresses the fact: for now, we
assume that child and parent products are tightly coupled, and forbid
child products in a range. You can only add the parent product (and
with it all children).
This requirement might be lifted in the future, but that will mean
additional complexity and we will see if it's necessary.
Closes #1253.
create_range method doesn't ignore existing ranges again
The functionality to have it fetch an existing range instead of loudly
complaining when a range already exists has been added as part of #1053.
But @codeinthehole and I agree that a method called create_range
shouldn't silently ignore an existing range, and can't think of a use
case anymore.
* Removed unused _save method. It's not called anywhere.
* Simplified comment and logic for display_order
* Reordered imports
* Used items() instead of six.iteritems() because create_range does not
get complex kwargs
* Removed a duplicate test
* Test for the correct exception
We only needed it because Django 1.4 shipped with a pretty old version
of six. Support for that has been removed, and Django 1.5 ships with six
1.6.1, which is more current than we required.
This nicely avoids an issue with django-extra-views pinning a six
version which caused the sandbox build to fail:
https://travis-ci.org/tangentlabs/django-oscar/jobs/32223978#L971
It only prevents adding a product to a range; offers can be applied
nonetheless (despite the docs saying otherwise). The same functionality
can be achieved by overriding get_is_discountable, so it can be safely
removed.
Issue #855 is caused when deleting the middle of three product images in
the dashboard. A quick workaround is to renumber the image order values
when deleting an image. Eventually, this should be readressed as part of
issue #856.
This commit is the squashed version of #1429.
Overide delete() on AbstractProductImage.
Ensures the display order is always in consecutive order.
Cleans up after TestProductImages is run.
Fixes #855.
Closes #1429.
Correct amount calculation when creating payment events in dashboard
The final line price was calculated as qty * qty * unit price, as the
line price was multiplied with the quantity for a second time. That's no
good.
Reported in #1442. Fixes #1442.
As Oscar depends directly on tables2 now, it should be returned as part
of get_core_apps, and has been removed from the requirements.txt and
INSTALLED_APPS calls.
Native migrations created with Python 2 differ from ones created with
Python 3. More importantly, they failed when used in Python 3, but not
vice versa. This is caused by field names being marked as byte strings
when using Python 2.
This rewrites the native migrations, which probably isn't a bad thing
either, because they were created with a pre-RC2 version of Django, and
Django 1.7 has since seen a few more migration-related fixes.
It's likely Django now does the correct thing and generates Python 2 and
3 compatible migrations under both versions of Python.
At the moment, we don't support setting is_discountable for child
products individually. This does keep things simpler when editing
products. If a use case crops up, it should be reasonably easy to
change.
* 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
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.
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.
I think the Oscar upgrade/forking process for forked apps will get
simpler with the new migrations. One probably will be able to just fake
an initial migration, or something like that. But for now, copying
them across as we did before should be a safe bet.
The app label needs to be the same that is used in the AUTH_USER_MODEL
setting to specify the custom user. For Oscar's AbstractUser, we
shouldn't set an app label; Django's autodetection should work in most
cases.
It in facts works for the test suite's custom user as well; but as we
specify app labels everywhere, we might as well specify it there.
Ignore capitalisation of local part of email address
Most email servers don't respect capitalisation, and many users don't
know about it. So Oscar now does what the rest of the world does, and
ignores the capitalisation when looking up an email address.
Fixes #1179.
Where I previously thought that renaming HTML/CSS is more hassle than
it's worth, @mbertheau convinced me that to update a codebase, a general
search-and-replace is the best approach already and will catch any
HTML/CSS changes.
I also missed to deprecate the min_variant_price properties.
David Winterbottom
Maik Hoepfel
Sergey Maranchuk
Markus Bertheau
Ziyad Soobhan
Johannes Schneider
Michael van Tellingen