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

Fixes #1064

For anon users, the basket ID is stored in a cookie.  Previously, this
was stored with a simple crc32 hash to prevent users enumerating baskets
by changing their cookies.  However, home-rolled encryption is always a
bad idea.  In this case, it may have probably exposed too much
information allowing the SECRET_KEY to be determined.

This change switches away from the home-rolled encryption to use
Django's built-in crypto signing functionality to store the basket ID.

Thanks to Raphael Kimmig for reporting this issue and providing this
patch.

This should greatly increase usability of the dashboard product update
page when managing a large amount of products.

Fixes #618

Conflicts:
	oscar/apps/dashboard/catalogue/forms.py
	oscar/apps/dashboard/catalogue/views.py
	oscar/static/oscar/js/oscar/dashboard.js
	oscar/views/generic.py

Widgets for product selection using select2 and ajax

To be more consistent with how access to products is handled in the
permission based dashboard, access to orders is now more permissive. As
long as one order line's partner has the current user in it's users,
access is granted.

Simplify implementation.

We no longer need to pass the StockInfo instance as the basket has a
reference to the strategy class and can fetch it for itself.  This means
we don't have to break backwards compatibility with Oscar < 0.6.

Prior to this change, it was possible to select child products in the
product dashboard. A new function get_parent_products_queryset was
introduced, analogues to the existing get_related_products_queryset. It
is not based on the BrowsableManager as I can envision scenarios where
that is extended to respect status fields or such like, which we should
ignore when selecting a parent field. Otherwise it wouldn't be possible
to e.g. add a few hidden products with child products.

Two issues in tests with the G library were fixed as well, were
unintentionally child products were created. If the product field is
left unspecified, it seems to pick a product instead of leaving it as
None.

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.

To support multi-currency sites.  This commit also made the order totals
a mandatory input for creating an order, which meant quite a few tests
had to change to support the new API.

It now returns a OrderTotal instance which has price fields with- and
without tax.

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.

Use field validators and model clean methods instead of forms.

Include new methods for voting up and down.

Add more tests.

This will become commonly-needed functionality.

I've changed my mind on this and think we should KISS. So the support
for the catalogue.*_product permissions has been dropped from the stock
dashboard. Clear case of feature creep, and it's easily added if needed.

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.

The name of link was changed when moving 'New category' button right top
to 'Create new category' to match consistency with others dashboard
pages.

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

Added tests as well.

Required updating tests.

Effective permissions are unchanged apart from catalogue views, which now
also allow users that have both partner.dashboard_access and
catalogue.change_product as permissions.

Includes tests.

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 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.