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.

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.

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.

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.

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.

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.

It just duplicates ProductRecord.score, makes ``oscar_calculate_scores``
slow and generally serves no useful purpose.

Also included docs for the previous changse to
``oscar_calculate_scores``.

Importing things in settings is discouraged. But until now,
OSCAR_SLUG_FUNCTION could only be set as a callable, which requires
importing. It's now been updated to use the import_string function.

Oscar uses explicit through-models for some ManyToMany relationships.
The expectation is that for each combinatination of the two foreign
keys, only one model can exist. But this hasn't been enforced until now.

Fixes #1309.

This completes the move away from partner wrappers to strategies. All
the methods for determining price and availability information have now
been removed from the partner classes.

The helper policy class ("DelegateToStockRecord") have been removed too
as they no longer have methods to call on the stockrecord.

This couples the methods and their bands together, and allows editing of
all bands in one page.

This was meant to be added in 0.7, but forgotten. Now, the Python,
Django and Oscar version in use are reported if OSCAR_TRACKING is
enabled. This helps Tangent to make informed decisions about what
versions of Python and Django to support, and how long to maintain older
Oscar versions.

The recently introduced management command makes customising easier, and
the docs have been updated accordingly. The how-tos could still do with
updating to the new command, but at least the main docs are current.

I just wanted to change one word, and then got sidetracked with
reordering the sentences.

This finishes the changes made in v0.6 where basket lines started
requiring a stockrecord FK. v0.7 handles the upgrade in middleware by
updating basket lines that didn't have a stockrecord. But since the
patch for v0.7 requires additional database queries, it's time to remove
it - which is what this change does.

This will be a slightly fiddly upgrade for some people as they will need
to run a data migration on their DB before applying the new basket
migration. I've included a sample snippet in the release notes which
should help.

- Rework the page on applying taxes in the US
- Update the release notes
- Update the "sandbox" page with details of the new site

Sphinx turned the double dash into a long dash. A user reported issues
with running the command after copy&pasting it.

(cherry picked from commit 90ab1f19f0)

Sphinx turned the double dash into a long dash. A user reported issues
with running the command after copy&pasting it.

They already existed, but were intentionally hidden from the list of
release notes prior to the release of 0.7 to avoid confusion.