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
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
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.
So we add handling to the filter where we check the value can be converted to a valid decimal. If not, return an empty string. Fixes #316
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.
Added new field to offer that allows their max num applications to be controlled. Dashboard adjusted to support this too.
This fixes a bug with adding customised products to the basket, where the clean method would get a MultipleObjectsReturned exception as the lookup wasn't taking options into account. Also fixed a display issue with required options in basket forms.
…re_datetimes Conflicts: oscar/apps/dashboard/ranges/models.py
* replaces all occurences of ``datetime.now()`` with ``django.utils.timezone.now()`` which returns aware or naive datetimes based on ``USE_TZ`` * increases ``South`` version to 0.7.6 in dependencies to make aware datetimes work in migrations. * Oscar's sandbox is now configured to use aware timezones by default