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.

* Document new datetime picker in release notes.
* Update the tests to new format
* Fix some PEP8 issues

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.

From #1435:
CommunicationEventType.category is used also to "detect" order-related
emails, in which case when previewing that email Oscar will put a
user-supplied order in the context for the email template.
This doesn't always work because the string that's saved in category
is localized.

Using choices remedies the problem. I don't think this feature is
commonly used, so no attempt at backwards-compatibility for
non-English setups is made.

South doesn't create a migration for this change.

Fixes #1435.

Closes #1173

Nothing major to see here. Improved the slightly horrid
TestCreateProductForm test class.

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.

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.

This commit updates the Getting started guide and highlights the upgrade
path for Oscar 0.8.

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.

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.

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.

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.