Hmmm, this turned out to be a monster commit.  This change allows the
basket to be able to correctly calculate prices including tax.

It also requires a whole load of test changes since all baskets now
require a strategy instance to be assigned.

Changes to stock validation are stricter now.

Verify that a correct URL leads to no redirect, and verify that an
incorrect URL leads to a redirect and the redirect has the correct URL.

It's not really needed as it doesn't make sense to simply add an address
to your addressbook as part of checkout.

Caused by reworking of the user creation form.

- Use a FormView (as it is a form view)
- Move the redirect URL validation into the form

This allows updating code in both places, if necessary. Getting Django
1.5 support would be painful otherwise. This also removes the circular
dependency of django-oscar-testsupport on Oscar.

The requirements were merged. The imports were updated
accordingly. Unused imports in the touched files were removed. No
further changes.

* Emailbackend: Updated to use REQUIRED_FIELDS
* Demo and sandbox site now use compat.AUTH_USER_MODEL as well
* Added example custom user that gets tested for Django >= 1.5

This is required to allow the pages component of the dashboard to
continue to work correctly.

Change to required address fields was causing the shipping address step
to fail.

This change introduces a templatetag which assigns context for adding a
'back to search results' link to a product detail page.  This can be
useful for certain types of user (who don't use the back button) and
want to get back to their, possibly complicated, set of search filters.

Fixes #456

The profile test can_change_password checked if the password change
form can be submitted succesfully, but did not verify that Django's
authentication system accepts the new password.

Product updates in the dashboard weren't being saved. This was a
regression introduced by my refactoring of the ProductUpdate/Create
views.

A test to ensure that a product title does indeed get updated has been
added.

Reported and fix supplied by @soloweb in #613. Thank you.

OSCAR_REQUIRED_ADDRESS_FIELDS allows setting which fields are required.
The use case is that post codes are expected to be required, but many
countries don't actually use them.

Before it was lower-casing everything first which prevented users being
able to login if their email address contained capitals.  We now only
lower case the host part as this is case-insensitive.

Fixes #505

A basic security measure to ensure a user is aware if his/her account
gets compromised.  The email contains a link to the password reset form
which allows a new password to be set.

Fixes #436

Fixes #413
Fixes #435

Following guidance from Tangent's UX team (blame them!)

* Split 'metadata' step into 'name and description' and 'restrictions'
* Add progress bar
* Add summary of entered data in right-hand sidebar
* Clean up breadcrumbs and URLs

Still needs from FED love.

Uses new status on offer model.

Link text had changed.

Required several schema changes:
* Add num_applications to offer model to track number of times an offer
  has been applied within an order.
* Add max_global_applications to offer model to set a limit on how many times an offer
  can be used.
* Add frequency to order discount to provide insight into how many times
  an offer was applied for a particular order.

Structure of dashboard changes to talk about offer 'availability'
instead of assuming a start- and end-date.

* Re-skin of the dashboard home page.
* Ensure the graph on the home page dashboard shows only 12 segments on the x-axis and not 24.
* Add auto refresh of 5mins to dashboard index

Fixes 366

Fixes #376

It didn't exist when I wrote patch_settings but now there's not point
having two versions of the same thing.

This allows admins to:

* Preview emails in the dashboard
* Send preview emails
* Save emails

Fixes #359

This involves various template changes to adapt to new bootstrap.

Also:

* New responsive sheets and added responive classes into templates
* Add navigation to accounts section
* Simplify product listing templates
* Product lists enlarged images
* Single promo in the side bar
* Add btn-full for button full width responsive
* Checkout nav slightly adjusted
* Add responsive nav into the accounts
* Correct CSS class-name typo
* Make empty basket message a bit more sensible
* Remove in-page link to product description
* Widen price columns on basket/checkout as some currency symbols start
  wrapping
* Add whitespace to detail page availability messages
* Remove snowcone from project

Issues:
Fixes #351
Fixes #349
Fixes #345

A user in Oscar is identified by email address instead of the
username. This is, however, not set as a ``unique`` constraint
in the user model in ``django.contrib.auth.models.User``. Checks
if an email already exists are carried out when a user registers
but are ignored when a registered user changes their
profile. This can lead to multiple users having the same email
address which should not happen.

I provide a failing test with a mixin that can be used in both
the ``UserForm`` and ``UserAndProfileForm`` to clean the email
field when validating the form. A ``ValidationError`` is raised
when a user with this email address already exists and is not
the currently edited instance (makes sure that profile updates
with unchanged email work still).

Fixes #324

* They are now known as 'stock alerts' instead of notifications.
* They have been moved into the customer app largely (instead of their
  own one).
* The model implementation has been simplified.

This is a squashed, rebased version of the original branch.

Original commit messages:

* product notifications are visible *only* if a product is not in stock
* or does not have a stock record (a new product).
* an anonymous user can sign up for a notification of a product. They
* receive a confirmation link that they have to open to activate their
* sign up. An anonymous user does not have any means of managing their
* notifications in a list. The confirmation email contains a second
* link, however, with a *unsubscribe* link that allows for disabling of
* the notification.
* a registered user can sign up for notifications without having to
* confirm it. When a registered user signs up for a notification, the
* "Notify Me" button disappears from the product information and is
* replaced by a note stating that the user has already signed up.
* registered users can manage (activate/deactivate) their notifications
* in their account settings.
* an anonymous user that has signed up for notifications and creates an
* account will pull in their notifications and have them assigned to
* their account and are then no longer marked as anonymous
* the notifications app registers a receiver for the ``post_save``
* signal of ``StockRecord``. Whenever a stock record is updated, the
* notifications are checked for this particular product and emails are
* sent out. These notifications are then disabled (not deleted) and
* marked with the date the email was sent. This hides the message from
* the registered users account. Notifications are still accessible,
* however, for staff members in the dashboard
* In the dashboard, the ``Customers`` navigation node is extended with a
* ``Notifications`` child that allows for editing, deleting and viewing
* all notifications. It also provides filtering capabilities for them
* based on status, customer name, customer email and/or product keyword.

The previous UPC validation in ``ProductForm`` broke updating the
a product. I realised this while digging around to fix the broken
``StockRecord`` issue that broke the CI build.

The validation now uses Django's validation of ``unique`` fields
instead and works.

The ``StockRecord`` issue was related to creating a form in the
update view providing stock record data in POST with ``partner``
empty. I corrected that and added a test case for it.