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
A user in Oscar is identified by email address instead of the
username. This is, however, not set as a ``unique`` constraint
in the user model in ``django.contrib.auth.models.User``. Checks
if an email already exists are carried out when a user registers
but are ignored when a registered user changes their
profile. This can lead to multiple users having the same email
address which should not happen.
I provide a failing test with a mixin that can be used in both
the ``UserForm`` and ``UserAndProfileForm`` to clean the email
field when validating the form. A ``ValidationError`` is raised
when a user with this email address already exists and is not
the currently edited instance (makes sure that profile updates
with unchanged email work still).
Fixes #324
* 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.
The previous UPC validation in ``ProductForm`` broke updating the
a product. I realised this while digging around to fix the broken
``StockRecord`` issue that broke the CI build.
The validation now uses Django's validation of ``unique`` fields
instead and works.
The ``StockRecord`` issue was related to creating a form in the
update view providing stock record data in POST with ``partner``
empty. I corrected that and added a test case for it.
Attempting to create a new product with a UPC that already exists
raises an ``IntegrityError`` instead of handling the ``ProductForm``
as an invalid form with an appropriate ``ValidationError``.
I fixed that by adding a ``clean_upc`` validation method to the
form by checking for an existing product by UPC. I am not sure if
that is the most efficient way to validate this. If there's a
better alternative, I am happy to change it...and learn something
:)
**Note:** I switched the functional tests in ``product_tests.py``
to use ``WebTest`` while I was at it.
Stopped treating checkout:index as a special case.
This view has a form that assumes anon checkout is allowed, which it
isn't always. Treating it as a special case was causing it to be
displayed when it shouldn't.
David Winterbottom
Jon Price
Sebastian Vetter
Sebastian Vetter
Asia Biega