This already worked only within site offers by way of default model
ordering. Site offers are probably the most common offers, however the
ordering of all offers has to be controlled by the applicator.
Conflicts:
tests/integration/offer/applicator_tests.py
Cherry-picked from #1414.
Don't create objects in the database unless necessary
Conflicts:
oscar/apps/offer/models.py
tests/integration/offer/combination_tests.py
tests/integration/offer/percentage_benefit_tests.py
@maikhoepfel duplicated the proxy class short-circuit logic for
Conditions as part of this commit.
Cherry-picked from #1414.
Update handling of child product for product ranges
This commit addresses issue #1253.
Currently, the offers app doesn't really consider child products;
behaviour is undefined. This commit addresses the fact: for now, we
assume that child and parent products are tightly coupled, and forbid
child products in a range. You can only add the parent product (and
with it all children).
This requirement might be lifted in the future, but that will mean
additional complexity and we will see if it's necessary.
Closes #1253.
* Removed unused _save method. It's not called anywhere.
* Simplified comment and logic for display_order
* Reordered imports
* Used items() instead of six.iteritems() because create_range does not
get complex kwargs
* Removed a duplicate test
* Test for the correct exception
It only prevents adding a product to a range; offers can be applied
nonetheless (despite the docs saying otherwise). The same functionality
can be achieved by overriding get_is_discountable, so it can be safely
removed.
Issue #855 is caused when deleting the middle of three product images in
the dashboard. A quick workaround is to renumber the image order values
when deleting an image. Eventually, this should be readressed as part of
issue #856.
This commit is the squashed version of #1429.
Overide delete() on AbstractProductImage.
Ensures the display order is always in consecutive order.
Cleans up after TestProductImages is run.
Fixes #855.
Closes #1429.
At the moment, we don't support setting is_discountable for child
products individually. This does keep things simpler when editing
products. If a use case crops up, it should be reasonably easy to
change.
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.
Where I previously thought that renaming HTML/CSS is more hassle than
it's worth, @mbertheau convinced me that to update a codebase, a general
search-and-replace is the best approach already and will catch any
HTML/CSS changes.
I also missed to deprecate the min_variant_price properties.
Replace countries.json fixture by management command
I started looking at this because on the mailing list, having the UK as
only shipping country led to confusion. This is mostly due to the
shipping address form hiding the country field if there's only one
country enabled, but all the validation then requiring UK postcodes and
phone numbers.
It's bothered me for a while that we're using a fixture to populate the
countries, which is at risk of becoming stale.
pycountry offers an excellent data source for a list of countries, so I
polished an existing management command to use it to populate the
country database.
This commit has two immediate effects:
* New setups will use a more current country database
* By default, all countries will be marked as shipping countries
pycountry also ships with localised names of the countries, which should
allow us to populate the database with localised country names.
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.
Product attributes had a mechanism to point at related model instances
in a generic way, but nobody managed to understand or get it working.
This comment removes that logic, including the AttributeEntity and
AttributeEntityType models.
Instead, this commit models the relation via a generic foreign key on
ProductAttributeValue.
I don't think there's a good default behaviour for the entity selection
as presumably each deployment will want to limit the selection in some
way. Therefore, there's currently no frontend support for it.
variants.json has been rebuilt by executing the migration and dumping
the correct data afterwards. That explains the other changes in it, as
usually we'd just use vim line matching to shape it into a form that
lets us build the sandbox.
* The get_validator method was dropped. Elsewhere we use the explicit
lookup by type, so why not there? It only makes adding custom
validation for e.g. richt text values more verbose, as both adding a
validation method and overriding get_validator is needed.
get_validator() was not used elsewhere in the codebase.
* The unused is_value_valid (used for option values) has been dropped.
The same check is already done in _validate_option.
They were in a bit of state, and are now using factories. Still far from
ideal, but I'd rather not change them too much while refactoring
attributes at the same time.
You can't easily create multiple users with the UserFactory without
using a sequence. I also wasn't aware that one can use the nicer
"factories" import instead of "newfactories".
Note that we can't easily use a LazyAttribute for the email address, as
the username may contain spaces.
Multiply charges when exceeding top bands upper limit
This approach imitates sending multiple parcels for a defined cost, and
hopefully approximates reality much better.
Note we still make some assumptions about the cost structure to avoid
having to solve an NP hard problem.
This commit also removes the unused max_upper_limit property and
replaces it by a more useful top_band property.
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.
Get weight-based shipping method to return charges again
Setting band.charge was accidentally killed in the refactor to the new
shipping method interface, so a correct charge was never returned. This
wasn't caught because there was no test for testing the actual shipping
charge calculation...
Both issues are remedied now. I'll have a more detailled look at the
shipping method tests when getting rid of upper_charge.
This (possible backwards incompatible) change means subclassing and
customising shipping methods becomes much easier. Now that shipping
methods are stateless, we can instantiate at compile time and assign
them to the repository instance.
This commit also renames internal methods of the shipping repository
in as the 'prime' notion is no longer valid (as we're not injecting a
basket into each method).
It now takes the shipping charge rather than the method. This makes
sense as the shipping charge has normally been calculated before we need
the order total so there is no point in calculating it twice.
Oscar now supports setting a price of zero for products.
Please note that currently a price of zero has no other special-casing
apart in a template. Notably, setting a currency is still required and
you can't add products to a basket of a different currency. This can
be improved if needed.
In the templates, the product price is displayed as "Free" instead
of zero (and whatever currency).
Writing an (initially failing) test exposed slightly incorrect handling
of the passed price in the stockrecord factory, as a price of zero
would always be replaced by the default price.
Fixes #1347.
This is a proposed change to show different styles of how we could
introduce unicode strings into the test suite. We should probably settle
on one of them.
Cherry-picked from 1e14af9
Conflicts:
tests/unit/address/factories.py
tests/unit/address/model_tests.py
Validate that basket additions have the same currency as the basket
And this is the outer-most frame of the Yak-shave: preventing the many
errors messages I get from the public sandbox site where people try to
add products of multiple currencies to their basket.
It was quite a journey...
Test basket's strategy class is correctly exercised by form
This shows the problem with forms knowing too much of the details of
collaborators. This is a design smell and will be looked at before
things get too stinky.
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.
This completes the move away from partner wrappers to strategies. All
the methods for determining price and availability information have now
been removed from the partner classes.
The helper policy class ("DelegateToStockRecord") have been removed too
as they no longer have methods to call on the stockrecord.
* WebTest throws a DeprecationWarning under Python 3 that we can't do
anything about. Added to the excludes.
* assertEquals has been deprecated, renamed to assertEqual.
Rename and move Scales class, and make it overridable
Making it overridable allows altering the weighing method of the basket,
which I wanted to do in a project. As get_classes doesn't support
importing from top-level products, it had to be moved to a scales
module.
Other class names tend to use singular, so as the imports had to be
changed anyway, Scales was renamed to Scale.
We need to bump the version of django-dynamic-fixture to get the test
suite to run under Python 3. They've dropped Python 2.6 support in the
same release.
The changes in 10bfa701 renamed get_query_set to get_queryset, which is
a change that only happened with Django 1.6.
A simple alias fixes the issue. Also added some tests for the manager.
Fixes #1294
[Backport] existing_user_fields: Fetch User model only when called
Otherwise it may cause Django start up pains, and does cause migrations
to fail. Thanks to Jonathan Moss for reporting.
(cherry picked from commit fa3f793a35)
Conflicts:
tests/integration/customer/test_custom_user_model.py
Sergey Maranchuk
Markus Bertheau
Maik Hoepfel
Ziyad Soobhan
David Winterbottom