Deprecate accessing categories without primary key
That approach is around from sometime around Oscar 0.6. With the
category refactor, it has become expensive to support. I doubt it has
any SEO impact, as e.g. Amazon has product IDs etc. all over their URLs.
@mbertheau seconded this opinion.
When we stopped storing the concatenated slugs on each category,
generating the URL for an individual category got more expensive. But
luckily it is safe to naively cache it, as the matching view only
considers the primary key any way. So even a stale cache should lead to
the right category.
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
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.
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.
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.
This involves various template changes to adapt to new bootstrap.
Also:
* New responsive sheets and added responive classes into templates
* Add navigation to accounts section
* Simplify product listing templates
* Product lists enlarged images
* Single promo in the side bar
* Add btn-full for button full width responsive
* Checkout nav slightly adjusted
* Add responsive nav into the accounts
* Correct CSS class-name typo
* Make empty basket message a bit more sensible
* Remove in-page link to product description
* Widen price columns on basket/checkout as some currency symbols start
wrapping
* Add whitespace to detail page availability messages
* Remove snowcone from project
Issues:
Fixes #351
Fixes #349
Fixes #345
* They are now known as 'stock alerts' instead of notifications.
* They have been moved into the customer app largely (instead of their
own one).
* The model implementation has been simplified.
This is a squashed, rebased version of the original branch.
Original commit messages:
* product notifications are visible *only* if a product is not in stock
* or does not have a stock record (a new product).
* an anonymous user can sign up for a notification of a product. They
* receive a confirmation link that they have to open to activate their
* sign up. An anonymous user does not have any means of managing their
* notifications in a list. The confirmation email contains a second
* link, however, with a *unsubscribe* link that allows for disabling of
* the notification.
* a registered user can sign up for notifications without having to
* confirm it. When a registered user signs up for a notification, the
* "Notify Me" button disappears from the product information and is
* replaced by a note stating that the user has already signed up.
* registered users can manage (activate/deactivate) their notifications
* in their account settings.
* an anonymous user that has signed up for notifications and creates an
* account will pull in their notifications and have them assigned to
* their account and are then no longer marked as anonymous
* the notifications app registers a receiver for the ``post_save``
* signal of ``StockRecord``. Whenever a stock record is updated, the
* notifications are checked for this particular product and emails are
* sent out. These notifications are then disabled (not deleted) and
* marked with the date the email was sent. This hides the message from
* the registered users account. Notifications are still accessible,
* however, for staff members in the dashboard
* In the dashboard, the ``Customers`` navigation node is extended with a
* ``Notifications`` child that allows for editing, deleting and viewing
* all notifications. It also provides filtering capabilities for them
* based on status, customer name, customer email and/or product keyword.