06c2441 changed the way actions are submitted for on the dashboard's
order list view. This commit updates the test to match the new
behaviour.

I'd also argue that the two test methods test different aspects of the
same thing, so I merged them, which saves us one (relatively slow) test
run.

The hidden widget means the tests have less set-up to do.

Currently, a product's stockrecords are used to decide if a user is
allowed to edit a product or not. That doesn't work for parent products,
because they don't have stockrecords. So it's not possible to decide
whether a user is allowed to edit a parent product (and e.g. create
children) for it.

As far as I'm aware, this is not a regression of the
permission-dashboard; I don't think it ever worked. It just hasn't been
spotted because nobody needed it.

This commit also adds some tests to ensure this is enforced.

The ProductCreateUpdateView had untested logic to handle invalid parent
products. Unfortunately, it didn't work; the check returned a redirect,
which later was tried to access like a product.

The only place to issue a redirect for invalid products is the dispatch
method, so an altered check has been moved there.

This time with tests...

It was broken without anyone noticing, as reported in #1451. My work in
PR #1441 magically fixed it, but we should still test it.

Fixes #1451.

Also sneakily fixes the wrong URL in the release notes for the previous
commit.

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 final line price was calculated as qty * qty * unit price, as the
line price was multiplied with the quantity for a second time. That's no
good.

Reported in #1442. Fixes #1442.

Nothing major to see here. Improved the slightly horrid
TestCreateProductForm test class.

This allows updating more than one order's status, similar to how line
statuses of an order can be updated.

This commit is a squashed version of the changes in #1391.

This is the result of wild grepping through the codebase. Nothing too
exciting to report, really. create_product now sets a products structure
to 'child' if a parent is specified.

I'd like to move away from django_dynamic_fixture, factory_boy is so
much nicer.

Previously, weight based shipping methods accepted an upper charge
field. When no weight band matched the baskets weight, this was
returned. I am not aware of a single retailer who calculates shipping
charges like that. It's impossible to pick a sensible value for a
retailer, as there's no upper limit to the amount of items ordered, and
any shipping charges would have to cover costs for that.

Not 100% sure if this is a good idea, but this commit adds a large
functional test that walks through most of the happy paths of the
shipping method dashboard. It's much simpler to write this journey in
one test method rather than separate test methods that require
progressively more set-up each time.

And write a *real* smoke test.

Reported by @martymcmahon in #1354.

Also added tests for changing the line and order status. Unfortunately,
I had to introduce test-global status pipelines instead of using
overridden_settings(). Even though I both applied it in setUp() and the
individual tests, the forms were rendered with no statuses available.

Fixes #1354.

Oscar already has child products to model tightly coupled products, and
"recommended products" to model products that are related (which we
expect to mostly be used for upselling). Product.related_products was a
third option that sat somewhere inbetween, and which I think will often
not be needed, has a mediocre interface in the dashboard and beyond that
no special treatment in the codebase. Furthermore, I see it being
confusing when trying to model a catalogue, and it's easily added back
if necessary.

Conceptually, save() is the wrong place for model validation. ModelForms
call clean() before saving, so the results should be the same as long as
they are used.

Fixes #1297.

This change includes some tidying and organisational changes. There's
also a new test for adding order notes.

Oddly enough, the warnings were only thrown under Python 2.6. Should
investigate!

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.

underscore as separator.
Changed setup of functional test in dashboard/communication to be passed
with code populated from name.

Using "partner" is easily confused with passing an actual partner
instance.

On my local machine, django-dynamic-fixture created product classes
where the slug and primary key were identical and the tests passed
although the check was wrong. Luckily, Murphy's Law works in our favour
on Travis CI, and that failed and spotted it.

This commit fixes the assumption that the redirect view expects the slug
(which it doesn't since the last commit), and ensures that the generated
product classes are non-numeric.

This gives more readable URLs.

Fixes #1186

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.

After creating a product, the flash message has links to
(a) view on site
(b) edit again.

ClientTestCase is deprecated.

Fixes #826
Fixes #1007

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.

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.

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.