Fixes stockrecord availability validation message in the case when stock is lower than allocation. Previously the message that appeared contained negative numbers. For example: "a maximum of -1 can be bought". Now it will display: "no stock available"
The offer tests contained a stray test case that I suppose was once
intended as a base class for all the other tests. But it's only used
twice, and for very little gain, so let's delete it.
Fix ValueError in tests when assigning unsaved instance
Django now throws a ValueError when an unsaved instance is assigned:
https://docs.djangoproject.com/en/1.8/releases/1.8/#assigning-unsaved-objects-to-relations-raises-an-error
This commit changes the offending lines to create objects in the
database instead. But I don't understand why I don't need to make
the same changes for e.g. the country factory.
But I don't really care, as long as the tests pass. I'm guessing it has
something to do with factory-boy and the get_or_create statement.
Unfortunately, this will make our test suite slower. But to make up for
it, Django 1.8 introduces the setUpTestCase method, which we can use
once Django 1.7 is removed.
The changes should be obvious and non-controversial. Under Django 1.7+,
the AppConfig is used to register signal receivers instead of just
registering then when models are registered.
This removes all the bits and bobs where we referenced South, or added
some code supporting it. Documentation will be updated in a later
commit, together with other Django changes.
Working on sets causes a random order of returned fields while using
existing_user_fields as reported in django-oscar/django-oscar#1597.
Changed to work only on lists, which remain correct
order.
Closes #1605.
Closes #1597.
The config was picking the wrong directory so the custom test templates
were not used during tests.
Notes
- Fix missing i18n load tags
- Remove mixed tab/space indentation
- Add two settings tests
Simplify and increase test coverage for PhoneNumberField
PR #1645 pointed to an issue with phone numbers. After digging into the
code for a while, I opted to redo the phone number field implementation
according to the Django documentation. It always takes me a bit of time
to grok descriptors; the new implementation avoids them.
Note that this does not fix any issue; it's just a simplication done
while searching for the bug.
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.
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
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.
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 test suite brings it's own stock record model for testing. Django
1.7 requires that we only import models from apps in INSTALLED_APPS, so
we need to use it to avoid clashes.
Add support for methods on User model when checking permissions
The ``permissions_required`` decorator, and hence
``Application.permissions_map`` and
``Application.default_permissions``, now
handle both methods and properties on the User model. Previously, it
wasn't supported, but a docstring showed ``is_anonymous`` as an example,
which is a method.
Drop upper_charge logic for weight based shipping methods
Previously, weight based shipping methods accepted an upper charge
field. When no weight band matched the baskets weight, this was
returned. I am not aware of a single retailer who calculates shipping
charges like that. It's impossible to pick a sensible value for a
retailer, as there's no upper limit to the amount of items ordered, and
any shipping charges would have to cover costs for that.