Better to use filenames which are commonly used in the python word then
custom ones.

Latter one is deprecated

We only needed it because Django 1.4 shipped with a pretty old version
of six. Support for that has been removed, and Django 1.5 ships with six
1.6.1, which is more current than we required.

This nicely avoids an issue with django-extra-views pinning a six
version which caused the sandbox build to fail:
https://travis-ci.org/tangentlabs/django-oscar/jobs/32223978#L971

The former throws a deprecation warning and causes the test suite to
fail.

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.

The new version has been extended to allow the success URLs and messages
to be easily customised.

We also now redirect staff members to the dashboard when they first
login.

Before this change, it was conflating WebTest functionality with the
Django test client. This change removes the Django test client
functionality (namely, the login function which was being automatically
called).

A shed-load of tests are adjusted to work with this change.

This almost completes the work for #826 - only a couple more references
to the Django client are left in the test codebase.

Previously, the 'key' kwarg was not respected and all products would get
added to the first wishlist.

Thanks to @DanielChu for reporting, and supplying a fix.
Fixes #1216

During the registration and in dashboard, the new password is required
to have min 6 characters and not be in common passwords. Those rules are
not enforced when changing password in the account section or resetting
password.

Extract password validators into core validators as they are used by
multiple apps. `password_validators` now contains all validators applied
to passwords: DRY principle.

Changed auth tests to have a proper password for password reset.

This should always be used instead of Django's silent version.

Previously, the test suite ran with a custom user model for Django >=
1.5, but it didn't subclass Oscar's AbstractUser.  This commit adjusts
the custom user model to subclass Oscar's so we can test functionality
within the custom user class.

This does require a change to the way tests authenticate as we don't
actually use the username field.

We add a new form to the profile section that requires the customer to
confirm their password, but which then deletes their user.

ClientTestCase is deprecated.

Fixes #826
Fixes #1007

Analogous to the settings for the basket cookie, the cookie that stores
the recently viewed products is now configurable.

Fixes #1064

Simplify implementation.

The locations of the form to re-order an order has changed, so the tests
needed updating.

This was a code change introduced in the refactoring, but does not make
any sense. Luckily, it also caused the tests to fail, so I'm happy to
revert it.

- 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 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 AccountSummaryView was trying to do too much and included random
bits from the other views. It has been changed to a simple
RedirectView. The redirect target can now be set with
OSCAR_ACCOUNTS_REDIRECT_URL and defaults to the newly-introduced
ProfileView. This leaves the UX unchanged apart from the fact that
was used to be scripted tabs is now separate views.

There was a lot of template duplication between the separate views. I
have introduced a PageTitleMixin and used this to significantly reduce
redundancy (e.g. hundreds of lines). This also led to removing a few
slight inconsistencies regarding headings, breadcrumbs etc.

The new templates have been categorised in subfolders.

Apart from the new ProfileView, I've had to introduce a simple
ProductAlertListView. I've also upgraded the ProductAlertCancelView to
be useful for both canceling from emails etc. as before, but also from
the ProductAlertListView.

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.

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 #376

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.

* Tests now split into more coherent modules
* Added IDs to forms to help WebTest
* Some refactoring along the way

With complete webtest for password resetting story.