Oscar 2.0 release notes¶
Welcome to Oscar 2.0. This is a significant release which includes a number of new features and backwards incompatible changes. In particular the way Oscar configures apps has been refactored and projects that have forked apps will need to follow the section on Migrating forked apps.
Oscar 2.0 is compatible with Django 1.11, Django 2.1 and Django 2.2 as well as Python 3.5, 3.6 and 3.7.
Support for Python 2.7 and Python 3.4 has been dropped.
What’s new in Oscar 2.0?¶
is_publicfield to the
Productmodel that is used to exclude products from the
browsable_dashboardqueryset is provided for use in the dashboard, which includes non-public products. This is a model change, so you will need to run the supplied migrations.
order.OrderStatusChangemodel that is used to log order status changes applied by
Order.set_status(). This is a new model, so you will need to run the supplied migrations.
OSCAR_OFFERS_INCL_TAXsetting which can be used to configure whether offer discounts are applied on the tax-inclusive amount. This defaults to
False, to preserve the original behaviour of discount application.
Added database index definitions for commonly queried fields in a range of models. See #2875. This will require projects that have forked Oscar apps to generate corresponding migrations.
filter_by_attributesmethod on the
ProductQuerySet, to allow database-level filtering of products by attribute.
Added support for re-ordering product images in the dashboard, and for adding an arbitrary number of additional images into the formset.
OSCAR_THUMBNAILERsetting can be used to customise thumbnail generation. Support is included for Sorl and Easy Thumbnails. The default is
oscar_thumbnailtemplate tag (to
image_tags) to generate thumbnails in templates. All uses of Sorl’s
thumbnailtemplate tag in the shipped templates have been replaced with
sorl-thumbnailhas been dropped as a dependency. Use
pip install django-oscar[sorl-thumbnail]or
pip install django-oscar[easy-thumbnails]to explicitly install the dependencies for either of the two supported thumbnailers.
Added the ability to manage
catalogue.Optionobjects from the dashboard.
Removal of deprecated features¶
Product alert emails are now sent as Communication Events and the deprecated product alert email templates have been removed. The templates for these emails have been replaced as follows:
Support for category URLs without a primary key has been removed.
Enforcement of unique slugs for categories has also been removed, as enforcing this was inefficient and not thread safe. Since a primary key is now required for category URLs, there is no need for slugs to be unique.
customer.forms.PasswordChangeFormhave been removed. Use
views.decorators.staff_member_requireddecorator has been removed. Use
UserAddress.num_ordersproperty has been removed. Use
Support has been removed for the dynamic loading of formset classes that were moved in previous releases. Projects must update their
get_classcalls to use the new paths. The paths that have changed are as follows:
action="."attributes, following the lead of Django and as per the HTML5 specification.
Replaced use of Django’s procedural authentication views with the corresponding class-based views.
OrderPlacementMixin.get_message_context()is now passed a
codeargument specifying the communication event type code for the message being sent.
We’ve dropped the dependency on Unidecode due to license incompatibilities,
oscar.core.utils.cautious_slugifyto handle Unicode characters in slugs when
Fixed input validation for
rangewas specified but other fields were empty.
Fixed calculation of weight-based shipping charges in cases where the basket weight is an exact multiple of a weight band’s upper limit.
catalogue.reviews.SortReviewsFormwas made optional and the logic in
ProductReviewListadjusted so that the form fields don’t have to be rendered manually because of form errors.
datetime_filterstag library that provides a
timedeltatemplate filter for rendering time deltas in human readable format.
OSCAR_OFFER_ROUNDING_FUNCTIONpreviously accepted a function as its value. It now only accepts a dotted path to a function as its value
Fixed the logic of
offers.Range.all_products()to make it consistent with
Range.contains_product()in excluding products specified in
catalogue.Categoryto restrict which fields are fetched from the database when performing category comparison queries.
Significantly improved the database efficiency of the
Order confirmation emails now include an order status link for authenticated users, as well as guest users, and order status is displayed consistently in both logged-in and anonymous order detail views.
Fixed display of styled HTML emails in account email detail views, wrapping them in an iframe to avoid leakage of styles into the page.
Bootstrap datetime picker JS/CSS assets removed from base layout, see #2584.
Oscar’s 500 error template no longer inherits other templates and does not use any template template tags and styling to avoid potential errors caused by the template itself (see #2971).
Line discounts are now capped to a minimum of zero - i.e., negative discounts will not be reported.
Backwards incompatible changes in Oscar 2.0¶
Redirection to the parent detail view for child products is disabled by default. Child products now have their own detail view, which allows displaying their price and images independently from the parent product. To revert to the previous behaviour of redirecting to the parent product, set
Renamed the modules containing the Django app config classes for Oscar apps (apart from the
appmodules of Oscar apps, moving the configuration (related to permissions, URLconfs, and feature hiding) they contained into the apps’ Django app config classes. They include the following attributes:
default_permissions; methods: :meth:
get_url_decorator, and :meth:
urls; and their respective view classes. The composite config classes for normal Oscar apps are subclasses of
oscar.core.application.Application), and for Oscar Dashboard apps
applicationvariable, which previously held an Oscar app config instance, from the Oscar app config module. A single Django/Oscar app config instance is now registered in the Django app registry, for each app label. It should be obtained by looking it up in the Django app registry.
Changed the values returned by the Oscar app config
urlsproperty. It now returns a tuple containing the list of URL patterns, the app namespace (which could previously be None, but not any more), and the instance namespace (which would previously be overridden by the app namespace, if left blank, but must now be explicitly set). To include URLs with an instance namespace, use the form
app_config.urls, and to include URLs without an instance namespace, use the form
oscar.get_core_apps. Overriding apps is now done by replacing the Oscar app entry in the
INSTALLED_APPSsetting with that of the forked app.
Changed the calling signature for the
oscar_fork_appmanagement command. The
app_labelargument is the Django app label of the app to be forked.
target_pathis the directory into which the new app shall be copied.
new_app_subpackageis the optional dotted path to the package of the new app, from which, together with the
target_path, the full Python path to the app will be derived. If
new_app_subpackageis omitted, then the package of the app being forked will be used instead.
promotionsapp. The app is now available in a separate package - django_oscar_promotions.
OSCAR_MAIN_TEMPLATE_DIRsetting has been removed and existing templates updated with the full path. See #1378, #2250. Please update your templates accordingly.
OSCAR_SLUG_FUNCTIONpreviously accepted a function as its value. It now only accepts a dotted path to a function as its value. Such functions must also now take a
Migrating forked apps¶
In release 2.0 the way apps are configured has been substantially refactored to
Application class with Django’s
AppConfig class. For
each app that you have forked, you will need to:
__.init__.pyto point to
AppConfigsubclass in the
apps.pymodule to either inherit from the parent app’s
AppConfigor use either
Move any changes you’ve made to the Oscar
Applicationsubclass in the
app.pymodule, to the
AppConfigsubclass in the
apps.pymodule. When moving the
nameattribute over, rename it to
namespace. Your merged app config class should end up having a
namespace(for declaring the URL application namespace) as well as
name(for configuring the
In your project URLconf and in get_urls methods replace the
applicationimport by finding the app in the Django app registry.
from django.apps import apps application = apps.get_app_config('your_app_name')
If the urls you’re including don’t define an instance namespace then use
include(application.urls), which only passes in the list of URL patterns.
Because of the way dynamic class loading now works, when forking dashboard apps, the
oscar.apps.dashboardapp also needs to be forked; and the forked dashboard app’s code must live inside the forked
Similarly, when forking
oscar.apps.catalogueneeds to be forked as well; and the forked
oscar.apps.catalogue.reviewsapp’s code must live inside the forked
mockas a dependency in favour of
bootstrapto version 3.4.1.
jquery.inputmaskin favour of
inputmaskand upgraded to 4.0.2.
tinymceto version 4.8.3.
offer.Range.contains()is deprecated. Use
catalogue.managers.ProductManageris deprecated. Use
catalogue.managers.BrowsableProductManageris deprecated. Use
catalogue.Product.browsableis deprecated. Use