We have differing logic on how to check the referrer for safety, which
should be bundled in one place. Plus it's annoying to have to remember
the typo in REFERER.

@aaugustin helpfully pointed us towards is_safe_url(), so that's the
best thing to use anyway.

Fixes #1221.

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

Calls to items() and values() return an iterator in Python 3. This
commit converts the result to a list if necessary. In some instances,
using the six helpers was not necessary and has been removed.

See also:
https://docs.djangoproject.com/en/dev/topics/python3/#dict-and-dict-like-classes

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.

This makes it easier for sites with dynamic subdomains to submit the
correct url in the password reset email without copying any code from
oscar.

Conflicts:
	oscar/apps/customer/forms.py

Cherry-picked from https://github.com/tangentlabs/django-oscar/pull/1367
by @maikhoepfel.

Closes #1367.

six is presumably better tested than our own code. Plus it allows us
using both urlencode and urlparse.

- Use correctly marked-up headings
- Ensure only active users can reset password
- Improve message on "done" template as Django 1.6 now allows form to
  validate even if there is no user with the given email address (so as
  not to leak information).

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.

Previously, despite required attribute was being overwritten when
importing the email fields from the user model.

Fixes #1237

I messed up when moving Alex Moon's code to oscar.core.compat and used
the wrong User model, defeating the point of the exercise.

This is fixed now, and the filter is also used for the UserForm that
gets used in the account section.

Fixes #1283.
Fixes #1282.

(cherry picked from commit 20df512eda)

Conflicts:
	oscar/apps/customer/forms.py

I messed up when moving Alex Moon's code to oscar.core.compat and used
the wrong User model, defeating the point of the exercise.

This is fixed now, and the filter is also used for the UserForm that
gets used in the account section.

Fixes #1283.
Fixes #1282.

Fixes #1239

It makes code a little bit more readable

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.

The forms string is a duplicate of another string apart from the dot.

The regexp error text was a bit too techy.

Thanks to OdifYltsaeb for reporting.

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

python-modernize (https://github.com/mitsuhiko/python-modernize) is a
useful wrapper around 2to3 which comes with sane defaults.

The fixes below were generated by running

    python-modernize --compat-unicode -w .

and then fixing all lint errors.

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

- Removed arguments for the password form that were not used
  (they are still catched by kwargs, not breaking backwards compatibility)
- Subject template is picked up from oscar/customer/emails folder.
  Removed unused template.

Flake8 was correctly throwing a warning that the function is too
complex. It's been split up into two functions now, and one level of
if-nesting has been removed.

This basically removes the code level concatenation of sentence parts
that make it impossible to translate this properly.

Fixes #1100.

Caused by reworking of the user creation form.

- No longer subclasses the auth view
- Uses a mixin for shared view functionality

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

All code handling email addresses has been update to use a new function
normalise_email, to have one consistent way of handling email addresses.

This function lowercases the domain part of an email address if it can
find an @, so it works on partial addresses as well.

Old imp. not Django 1.4 compatible

This can be used by new Oscar installs.  It's the same as a the core
Django one but without a username.

The new model must have an email field but Oscar will work without
anything else.

These are simpler as they are guaranteed to have an email field which
Oscar uses for authentication.

Fixes #719

- Merged PartnerUpdate and PartnerUserList view for a better UX
- Created new ExistingUserForm to allow for updating user details
  without changing password
- PartnerUserUpdateView now enforces user being associated to partner
- Added Undo link when unlinking user
- Enrich user details when creating in form instead of view

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

As suggested by @jerzyk in #394.

* Change '%' in the translation string to %% as it is being treated as
  part of string formatting

* Includes a migration for the proxy_class field
* Dashboard templates needed adjusting

Fixes #386

This allows admins to:

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

Fixes #359

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