Oscar's policy is to support two versions of Django. So while there
isn't a major reason to drop support for Django 1.5, dropping support
for Django 1.6 once 1.8 is released will reduce complexity considerably.

It is the only model in any of the Oscar dashboard apps. It causes an
issue with the get_model() call, because the dashboard app labels had
to be renamed for Django 1.7. So in Django < 1.7
get_model('ranges', 'RangeProductFileUpload') would work, wheras in
Django 1.7 it had to be get_model('ranges_dashboard',
'RangeProductFileUpload'). There is other ways of solving the problem,
but given that it is a rarely used model of temporary nature, enforcing
that dashboard apps are models-free seems like the cleanest solution.
This only has to be enforced till support for Django 1.6 is dropped, and
I doubt we'll see the need for a model in a dashboard app till then.

This prevents an IntegrityError from slugs clashing after renaming a
range to avoid the checked-for name clash.

Fixes #1424

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.

It must be left over from more glorious times.

This is the squashed version of #1369.

Closes #1369.

The Django admin often enough does not work or not as expected; that
isn't communicated clearly enough. This commit hopefully clarifies
things a bit.

I started looking at this because on the mailing list, having the UK as
only shipping country led to confusion. This is mostly due to the
shipping address form hiding the country field if there's only one
country enabled, but all the validation then requiring UK postcodes and
phone numbers.

It's bothered me for a while that we're using a fixture to populate the
countries, which is at risk of becoming stale.
pycountry offers an excellent data source for a list of countries, so I
polished an existing management command to use it to populate the
country database.

This commit has two immediate effects:
* New setups will use a more current country database
* By default, all countries will be marked as shipping countries

pycountry also ships with localised names of the countries, which should
allow us to populate the database with localised country names.

* Added some docstrings because I kept having to look up details
  of the implementation
* Removed index on the alpha3 and numeric code because we never use
  those fields for lookups
* Turned the numeric field into a CharField as suggested

As it came up on the mailing list again, I've clarified a few more
scenarios of what needs to be done with migrations when upgrading.

This was somehow overlooked. Also added a missing
parent_availability_policy on the Structured base class.

This is the result of wild grepping through the codebase. Nothing too
exciting to report, really. create_product now sets a products structure
to 'child' if a parent is specified.

Deferred benefits could reasonably make use of that information.

Templates need access to both ancestors and descendants of a
category, and ideally both including the category itself or not.
Previously, get_ancestors used to default to including the category
itself, which required slicing in templates. Also, get_ancestors is a
treebeard function and I wouldn't bet that it doesn't interact with
treebeard logic.

Now, the two treebeard functions get_ancestors and get_descendants
return a queryset, and get_[ancestors|descendants]_and_itself return a
list that includes the category itself.

Oscar by default deleted image files and thumbnails. That is usually
fine, but has been an issue when using remote storages like S3. This
change also makes the only remaining import from sorl optional, hence
paving the way to making it completely optional.

Fixes #1373.

This includes two examples for product attributes.

Also fixes two "document not referenced" warnings.

Fixes #794.

A 255 character limit seems somewhat arbitrary. And if there's
performance issues, using product attributes probably isn't the right
approach anyway.

This commit replaces the migration to decrease clutter.

Fixes #1380.

Two people on the mailing list tripped over the location helper, so it's
now included right next to where it is used.

The helper is now also used in a few more spots in the settings.

Product attributes had a mechanism to point at related model instances
in a generic way, but nobody managed to understand or get it working.
This comment removes that logic, including the AttributeEntity and
AttributeEntityType models.

Instead, this commit models the relation via a generic foreign key on
ProductAttributeValue.

I don't think there's a good default behaviour for the entity selection
as presumably each deployment will want to limit the selection in some
way. Therefore, there's currently no frontend support for it.

variants.json has been rebuilt by executing the migration and dumping
the correct data afterwards. That explains the other changes in it, as
usually we'd just use vim line matching to shape it into a form that
lets us build the sandbox.

* The get_validator method was dropped. Elsewhere we use the explicit
  lookup by type, so why not there? It only makes adding custom
  validation for e.g. richt text values more verbose, as both adding a
  validation method and overriding get_validator is needed.
  get_validator() was not used elsewhere in the codebase.
* The unused is_value_valid (used for option values) has been dropped.
  The same check is already done in _validate_option.

@hkage raised a good point in #1384
that concatenating the address lines might lead to
a string that's longer than the set limit of 1000 characters. If I
recall correctly, a CharField limit much higher than 255 characters is
troublesome with some databases anyway, so I've taken the opportunity to
turn it into a TextField instead.

Fixes #1384.
Fixes #1385.

Oscar creates unique order numbers by default (and so should you!). But
it wasn't set as such in the field decleration, which is now remedied.

Reported in #1194. Thanks!

Fixes #1194.

This also changes it's interface to

{% basket_form request product 'single' as basket_form %}

Before it was the weird

{% basket_form request product as basket_form single %}

However in this form the assignment_tag decorator can't be used.

Cherry-picked from
1aa64c39da
by @maikhoepfel. Docs by @maikhoepfel.

Conflicts:
	oscar/templates/oscar/catalogue/partials/add_to_basket_form_compact.html
	oscar/templatetags/basket_tags.py

Fixes #1377.

This approach imitates sending multiple parcels for a defined cost, and
hopefully approximates reality much better.

Note we still make some assumptions about the cost structure to avoid
having to solve an NP hard problem.

This commit also removes the unused max_upper_limit property and
replaces it by a more useful top_band property.

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.

The howto recipe on shipping has been rewritten to describe the new
changes to shipping functionality. The old shipping app reference has
been merged in too to avoid duplication.

The non-camelcased class has bothered me for a long time.
We can remove the deprecated spelling for version 1.0 :)

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.