Symptom:
Adding to basket did not work
Cause:
Was not passing the request variable as part of the context and so the
basket form could not be generated. Hence adding to basket led to an
error.
Solution:
Add request to the context returned by the helper function.
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
Add reverse relations to preselect_related on category view
The availability wrapper needs to look at a product's class, which gives
two extra DB lookups for each product in the list. This adds 50 DB
queries to the listing view and makes everybody sad.
This fix looks a little ugly but reduces the number of queries to ~25
(with cache enabled).
Consumption now sorts the basket lines in descending price order so that
the most expensive products are consumed first. This means that
multibuys apply in a more natural way.
Fixes #348
Almost all textareas have it enabled. The corresponding variables in
the main templates have been marked 'safe'.
There are a few areas where the whitespace around the description isn't
quite right. Will fix later.
The widget is enabled by setting a class on the form 'wysiwyg'. It's
much easier to use the form classes as you don't normally have access to
the textarea classes directly. To do that, you would need a custom form
widget and to build each form class to use it (rather than relying on
modelforms). We may have to switch to this at some point if the current
implementation becomes too clunky. We'll see.
Add fix for OrderDiscount model when offer deleted
The OrderDiscount did not store (a copy) of the offer
name within a separate field which causes an issue when the
offer is deleted. E.g. it breaks the order history view for
the customer because no offer data is available.
I have added a new field to OrderDiscount that is automatically
populated from the offer.name field. This works in the same way
as voucher_code does in the same model.
I also found two issues with the voucher implementation within
the same model that are fixed now.
Fixes #330
Move basket status constants onto the Basket class
It was a mistake to have them at module level as it meant it was a pain
to import them when they were needed for filtering. Having them on
the basket is much nicer as they available whenever the Basket class is.
This commit may cause a few gremlins for people updating to 0.4 but I
think it's a necessary pain at this stage. It's trivial to fix too.
This requires a new templatetag that annotates the field with the widget
type. The motivation is so that normal forms (not using
form-horizontal) can render checkboxes differently - wrapping the input
in the label element. This is advocated by bootstrap amongst others:
http://twitter.github.com/bootstrap/base-css.html#forms
At the moment, checkboxes rendered in a form with class
'form-horizontal' don't look right - they need some adjusting in the
CSS.
This makes it easier to use the Oscar form mark-up but rending a form
manually.
For example::
<form action="." method="post">
<legend>First set of fields</legend>
{% include 'partials/form_field.html' with field=form.name %}
{% include 'partials/form_field.html' with field=form.description %}
<legend>Second set of fields</legend>
{% include 'partials/form_field.html' with field=form.start_date %}
{% include 'partials/form_field.html' with field=form.end_date %}
</form>
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.
David Winterbottom
Jon Price
Dan
Dan Atkinson
Sebastian Vetter
Oliver Randell
Sebastian Vetter
Marek Brzóska
Asia Biega