This allows importing a class or attribute by the reasonably common
string notation, which is useful for e.g. settings. When using settings,
we should prefer absolute imports over using get_class, because that
limits us to modules in INSTALLED_APPS.

* Made upper_limit a DecimalField, like the other weight fields
* Increased default precision for weights to be to the gram level. Will
  be useful for deployments shipping smaller items such as stickers,
  where 10 grams precision is too low.
* Changed strings to official 'kg' abbreviation.

Making it overridable allows altering the weighing method of the basket,
which I wanted to do in a project. As get_classes doesn't support
importing from top-level products, it had to be moved to a scales
module.

Other class names tend to use singular, so as the imports had to be
changed anyway, Scales was renamed to Scale.

The function essentially does two things:
1. it applies a prefix - the first argument - to the given urls. In no
   instance a prefix was given
2. it calls url() for simple tuple or list elements in the given iterable.
   Cases where such a tuple or list was passed to patterns have been
   replaced by direct calls to url()

2 allowed for both calls to url() and simple tuples to be listed in
get_urls() and similar places. This allowed for unnecessary variation.
Always calling url() makes the url lists look less noisy and more uniform,
allowing the reader to focus on the actual differences of the urls instead
of superfluities.

django.conf.urls.patterns will also undergo deprecation starting from
Django 1.8. This commit anticipates that change.

https://docs.djangoproject.com/en/dev/releases/1.8/#django-conf-urls-patterns

Tests currently don't pass, but I'm hopeful they will in time for the
release of 0.8.

Those are the release notes for the changes in #1296

Intentionally did not link the new document from the index because 0.7
isn't released yet.

Changing a unofficially deprecated model name is clearer than having
three places to get at the same model.

The name 'AbstractBase' is consistent both with our naming of other
abstract models, and lots of apps having a Base class.

This is a common and useful Oscar pattern, and there's no reason to not
use it for the shipping app.

They are not imported anywhere in Oscar and just provided for
convenience, so no imports had to be altered.

Underscore does not seem to have meaning in Sphinx, was rendered as-is.

This has been impossible so far. It is easily achieved by setting
can_delete=True on the formset.

I spent some time trying to get the nice solution working, which would
be that assigning an empty category means deleting that ProductCategory
instance. But I haven't found a good solution that avoids problems like
in #1267. I have since come to the conclusion that enabling can_delete
is the right thing to do. One can then explicitly hide the checkbox,
but set the correct hidden field in Javascript on the client side if
an empty value is assigned.

The fields section has been moved from the factory declaration to the
ProductForm Meta class to allow for easier customisation.

Fixes #1289

I struggled, so I thought I'd document it.

A few little bits caught my eye. Moved the django-compressor tip nearer
to the section about INSTALLED_APPS.

Plus write some release notes.

Fix a few factual errors and specify the correct URL for cloning Oscar.

This makes the docs navigation a lot more useful, and it gives it a bit
more coherent structure.

Reasoning about e.g. when it is feasible to drop Python 2.6 or Django
1.5 support is hard without reliable data, hence the tracker pixel has
been extended to submit the Python and Django version in use. Tracking
is still easily disabled by setting OSCAR_TRACKING to False.

This Javascript plugin was used to style browser scrollbars in a
cross-platform way. I belief it's better to remove it:

a) It doesn't do anything, at least on my Ubuntu Chrome nor Firefox.
b) I'm sure there's decent reasons why there isn't a cross-platform
way to style scrollbars. It's a liability when it comes to smartphones
and tables, because those scrollbars use a different UI.
c) It's easy to add back again if so desired.

The new recipe has a working example on customizing the behaviour Oscar
does when a customer places a successful order.

This is pretty much what I use for bikepartsmarket.com. If this gets
some more eyeballs, it might mature enough to move into Oscar core.

This required:
* Moving Django's i18n urls into the main urls.py and outside of the
  scope of Oscar's main application class, because they need to live
  outside of the scope of i18n_patterns
* Add a language-code stripped version of the current URL to the
  template context to get the language switcher working.

I also updated the language switcher code to mimic what is currently
given as an example in Django's docs.

Fixes #797

It was empty before.

Warning added by @maikhoepfel.

It is now replaced with a checkout pre-condition that applies to every
checkout view. If someone's basket becomes invalid while they are in
checkout, then they will be redirected back to the basket page.

There were slated for removal in 0.6. The release notes contains info on
what replaces each method.

It is replaced by the new pre-condition checking.

Fixes #1266

Just crossing items off my bucket list.

The data migrations convert any field values that are None to ''.

After second thought, the field changes on ProductAttributeValues have
been undone again. It seems more consistent with the other fields.

This was missed so far. Oops, sorry about that!
Any existing deployment will have to run

$ ./manage.py migrate reviews 0001 --fake

That was an oversight. Don't think it caused any harm.

It's been unofficially deprecated in 0.6 already.

A canonical product should never have it's product class deleted. Thanks
to @mbertheau for suggesting.

Partner name's are allowed to be empty, but Line.partner_name wasn't.
This caused orders to fail when the partner name was indeed empty, as
reported in #1206.

So the field options for both have to be identical. Unfortunately, that
means allowing null=True for Line.partner_name. But dropping null=True
from CharFields should be done as a separate effort all over Oscar's
codebase.

Fixes #1206.

We send the user's email address too.

* It can now be specified in OSCAR_DASHBOARD_DEFAULT_ACCESS_FUNCTION
* nav.py and menu.py were split up so that Node can be dynamically
  loaded and hence overridden

I recently needed to alter the access function and realised it's not as
easy as I thought.

Allow using a different app than promotions as the homepage view.

This required extending the offer factories to support setting the
start- and end-dates (looking forward to using FactoryBoy now).  Some
additional tests were added for the active manager.

Fixes #1128