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.
Parent/child products aren't supported in permission-based dashboard
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
Correct amount calculation when creating payment events in dashboard
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.
Ignore capitalisation of local part of email address
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 test suite brings it's own stock record model for testing. Django
1.7 requires that we only import models from apps in INSTALLED_APPS, so
we need to use it to avoid clashes.
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.
Drop upper_charge logic for weight based shipping methods
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.
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.
When ordering a basket of free products, or with vouchers giving 100%
discount, we should not collect payment details.
To achieve this, I've added a check to the CheckoutSessionMixin which
calculates the order total and decides whether payment is necessary.
The modified test failed because the OrderCalculator called by
check_payment_is_necessary accessed other properties on the shipping
method. We now just mock a valid shipping method, which still achieves
the aim of ensuring there's only one.
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.
This is quite a large change. It:
- Alters the add-to-basket URL to have the "base" product's PK in it
- Changes the constructor of the AddToBasket form to not require
purchase_info (even though I only just introduced it!)
- Renames the product_id field to variant_id and only uses it for group
products
These changes are motivated by the variant workflow. Before this change,
you effectively had different forms being used for rending and
validation as the product being passed to the form constructor was the
group product when rendering but the variant when validating. This just
about worked but was not nice.
The purchase_info param is removed as we can only calculate the
purchase_info once the variant product has been validated. Hence we
again violate Demeter and make a deep call to the purchase info
calculation within the basket form. Might revisit this again.
This change also simplifies the basket view logic and allows a form to
be removed.
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 means we don't need to do the law-of-demeter-violating call to
fetch the purchase info for a product (line 79 of forms.py). HOWEVER,
I'm starting to have second thoughts about this - I've discovered that
the adding to basket process is quite confusing for variants and I
intend to refactor.
This commit also adds some useful tests though so it's a valid stepping
stone to a better place.
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.
Disentangle Django's test client from Oscar's custom webtest class
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.
It is now replaced with a checkout pre-condition that applies to every
checkout view. If someone's basket becomes invalid while they are in
checkout, then they will be redirected back to the basket page.
Checkout index view enforces basket must be non-empty
This change introduces a new framework for enforcing checkout
pre-conditions. Each view class can define a class attribute
'pre_conditions' which lists method names to run before the class
itself.
Of course, decorators are more conventional for this kind of thing but
they are harder to override and customise.
Incorporate ProductListView into ProductCategoryView
Now that Oscar's simple search has been removed, ProductListView does
nothing but show all products. It's been incorporated into
ProductCategoryView.
ProductListView used to give out an invalid summary; this is now fixed.
ProductCategoryView used to pass 'categories' in the template context,
but it wasn't used.
Maik Hoepfel
David Winterbottom
Markus Bertheau
Michael van Tellingen
Shafique Jamal
Vladimir Bolshakov