Add docstrings to the following classes in 'oscar.apps.shipping.methods':
* Free
* FixedPrice
* TaxExclusiveOfferDiscount
* TaxInclusiveOfferDiscount

Fix typo in 'docs/source/howto/how_to_configure_shipping.rst':
* Change 'shipping.addr' to 'shipping_addr'

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.

Registering receivers is a tricky business pre-Django 1.7 as they get
registered at the same time when models get registered, but require the
sending model to already be in the app cache. It's surprising we don't
see more issues!

Recommendations:
* Avoid calls to get_model in modules that get called during app init at
  all cost
* Don't use get_model in your own code. Just import directly.
* Switch to Django 1.7 :)

This commit probably fixes the issue in #1205. But get_model calls to
fetch the category, product image and stock record will all fail,
because receivers listen to their signals.

This commit also moves the catalogue receiver into it's own receivers
module, because that's how we do it elsewhere. That won't make a
difference to the issues though.

Closes #1173

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.

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.

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.

Copy-paste fail.

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.

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.

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.