When i try to create the order, i saw:

/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField received a naive datetime (2012-11-23 02:53:29.456187) while time zone support is active.
  RuntimeWarning)

And that:

  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/plata/shop/forms.py", line 72, in save
    order.save()
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/plata/shop/models.py", line 172, in save
    super(Order, self).save(*args, **kwargs)
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/models/base.py", line 463, in save
    self.save_base(using=using, force_insert=force_insert, force_update=force_update)
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/models/base.py", line 551, in save_base
    result = manager._insert([self], fields=fields, return_id=update_pk, using=using, raw=raw)
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/models/manager.py", line 203, in _insert
    return insert_query(self.model, objs, fields, **kwargs)
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/models/query.py", line 1593, in insert_query
    return query.get_compiler(using=using).execute_sql(return_id)
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 910, in execute_sql
    cursor.execute(sql, params)
  File "/home/nvbn/work/totemi/ENV/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 52, in execute
    return self.cursor.execute(query, args)
DatabaseError: value too long for type character varying(3)

after I add a product in admin view and I try to view it I get the error:
'ProductAdmin' object has no attribute 'show_on_top'

Thanks,

Cristian

Hello,

You have some FIXME comment in your code.
I think this in related to the fact that one folder in the path does not have init.py in it.
See http://stackoverflow.com/questions/338768/python-importerror-no-module-named
Else, as far as I tried there are a lot of inconsistency code in the head commit.
Anyway, maybe is my fault.
Thanks,

Cristian

Hi,

The documentation suggests using django_polymorphic to get different product types going. Are there any examples of available for this?

Felix

Hi,

The default behavior for payment processors when an error is encountered seems to be the HTTP error 403 "Forbidden" response. This particularly applies to ipn() method as there hasn't been a case yet where it is possible that process_order_confirmed() will raise an error.

I am writing a payment processor for a service with a REST API that will return "success" or "error" upon payment record creation using that API. While I can handle the error using the same code 403 response, I would much like to handle this case with some application logic: set a flash error message (messages.error(request, ...)) and return to the confirmation page. In fact, I would like to be able to do that in the ipn() method as well -- it wouldn't disturb user work-flow unlike error 403.

Currently there is no API to give the opportunity to redirect payment processing errors to some application-level logic or even to the "failure URL" provided to the payment processor. I would like to open this feature for discussion (and possible implementation by myself or someone else).

Do you think it is OK to add to DiscountBase class a method to retrieve a list with product_variation and new price (after we apply discount).
Or is a method to get a list with discounted products variations (without making an order)?

Thanks.

Cristian

See also feincms/feincms@6994748

Hi,

Can we remove unavailable product variations from "Add to cart" form?

No time to look into it right now, but leaving a note for later. Everything else seems to pass

======================================================================
ERROR: test_01_products (testapp.tests.admin.AdminTest)
Test whether the administration interface is well behaved
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/Data/Repositories/plata/tests/testapp/tests/admin.py", line 81, in test_01_products
    self.assertContains(self.client.post('/admin/discount/discount/add/', discount_data),
...
File "/Volumes/Data/Repositories/plata/plata/discount/admin.py", line 117, in get_fieldsets
    _discount_admin_state._plata_discount_config_fieldsets)
AttributeError: 'thread._local' object has no attribute '_plata_discount_config_fieldsets'

Tests result - https://gist.github.com/4133268

Is there such option in Plata?

I've grepped through the code, and found a field "shipping_method" in the Order model, but I did not find where it is set.

The use case is simple: the user can choose between several shipping methods with different costs, and after that, the costs are added to the bill.

using examples/custom raises an error

plata/shop/views.py in init, line 300

Check out, fill form, confirm, back to Cart, checkout again.

This is necessary if for some reason the tax rate changes (as is the case this night in CH...)

Hi,

first of all: thanks for the shop! It's fun to work with it.

At the moment, I'm stuck. I cannot find any solution for my current problem: How can I extend the OrderItem with more model fields?

The problem seems to be the Relation between the OrderItem and the Order. The Order creates OrderItems which are defined by the related_name "items". So an own class "MyOrderItem" won't work here.

Do you have any hints for me?

Thanks a lot,
Timo

Either create a new form or adjust the plata.contact.CheckoutForm.

This will be especially necessary when you have subscriptions.

url: /shop/products/1/

When I click "Add to cart" button, I'll get an error page ():

DoesNotExist at /shop/products/1/
No exception supplied
Request Method: POST
Request URL: http://127.0.0.1:8000/shop/products/1/
Django Version: 1.4.1
Exception Type: DoesNotExist
Exception Location: PROJECT_DIR\plata\product\models.py in get_price, line 41
Python Executable: C:\Python27\python.exe
Python Version: 2.7.1

I've added a price for my product, but it seems that the get_price() didn't get a price, and then the 'except IndexError' executed, but 'self.prices.model' is not a model?

Python Version: 2.7.1
Django version: 1.4.1
Database: MySQL 5.0.67

Thanks.

When I click "Proceed to payment" button, I'll get an error:

AttributeError at /shop/confirmation/
'PaymentProcessor' object has no attribute 'redirect'

Error place may be at line 42 of plata\payment\modules\cod.py:

return self.redirect('plata_order_success')

Thanks.

... without them having to enter a discount code.

Test which name and SKU is copied to the order item.

Hi,

I use plata 1.1 and needed to change the currency. So I added the new currency in settings.CURRENCIES and created a new product. The problem is that existing users had their contact information already set and using the other currency.

The result is that it was impossible for existing users to add products in the new currency to their cart because the product would not exist with the old currency.

To allow further use of the website, I manually updated all contact entries in the database to use the new currency. I don't know whether this is a bug or not but I thought I'd report it.

And many thanks for this django app. It is simply excellent!

Hi,

Thanks for writing Plata!

For my needs right now your plata.product.modules.options.models.Product model seems right. However, getting django to see it is a pain.

What I'm currently doing is creating my own app and importing your models into its models.py: from plata.product.modules.options.models import *).

It would be nice if there was a way that didn't feel so kludgy. Do you have any recommendations?

Cheers,

Tom

Showing that stock is not available on cart submission only is a little bit late.

This applies to v1.2.0 Maybe has been resolved already.

Once in order_modify_item_form during validation and then when added to the cart.
This happens in the same request/response cycle and should therefore be cached somehow.

We have a shop that has one complex product (lots of configuration parameters) and a bunch of simpler ones.

Ideally we'd have two different product models for each but that doesn't seem possible in Plata.

What's the recommended way to handle this scenario?

(I'm aware this isn't really an issue but in the absence of a discussion group I thought this might be the best place to ask)

Will plata support Alipay payment?

Currently django 1.5 is in beta.

I've looked over the source. While for some models it is as simple as switching the foreign key to User to settings.AUTH_USER_MODEL, for other parts such as the BaseCheckoutForm where it relies on users having email addresses, it can get more complicated.

What can I do to help?

Hi Matthias,

I think that Plata is great shop solution and by looking at the code I get impression it's finished product implemented many times, I would like to make suggestion. Generally I have feeling that some things could be more abstract, and thus more adaptable to specific needs.

For example ProductPrice model is currently related to Product model. In real world, pair of shoes can have different price depending on size. I am not sure how easy it would be to adopt current models for this need. I have a feeling that ProductVariant should answer this questions in abstract way and subclasses would have concrete implementation.

Similiar things that might make both developing plata and implementation simpler is if one could subclass AbstractProduct and override taxes, currency, availability related methods to his own needs.

these was just my 2 cents.
bets,
Bojan

It's not clear from the documentation that the "default currency" is considered to be index 0 of the CURRENCIES list. It might save others a bit of pdb'ing to figure out why they keep getting "exception not provided" when trying to add to cart something that isn't CHF. Perhaps a DEFAULT_CURRENCY setting that takes a 3-character currency string would be more explicit?

I'm also not certain that this error is normal, because even without modifying my CURRENCIES setting, Shouldn't I should by default be able to add products with a price set to be any of the 3-character currency strings provided by the default (CHF, CAD, USD, EUR) to my cart? I have no difficulty creating the product with say, USD as the currency in the admin. However, when I go to add it I get a "No exception supplied" DoesNotExist.

Changing my CURRENCIES setting to put USD as the first one gets me past the error, but it doesn't seem to be working as intended.

Any ideas Matthias?

EDIT: It seems that modifying the CURRENCIES list did not solve the issue. Pdb reveals that "currency" is always None in get_currency() of ProductBase, which does not seem to be intended behavior. Also, orderitem.currency() seems to only return "CHF", despite the product having a price specified in USD. I'm going to clear out .pyc's and the database to see if that solves it.

EDIT: OK, after removing all .pyc and dropping/recreating the database I think the problem seems to be the following: Say I have CURRENCIES = ("USD", "CHF", "EUR", "CAD"), and I create a product with a price in USD. I am able to proceed normally with adding to the cart and completing an order. However, if I create a product with a price in CHF, EUR, or CAD, attempting to add to the cart fails with a DoesNotExist exception.

FINAL EDIT: So it seems that in order to have multiple currencies, you need to override default_currency() on your Shop instance and provide the functionality yourself. Perfectly reasonable now that I know, but the documentation should probably reflect that the first currency listed in CURRENCIES is the only one that will work out-of-the-box without overriding the default implementation of default_currency().

Plata uses email for login:

forms.py, line 67

if getattr(User, 'USERNAME_FIELD', 'username') == 'username':
    params['username'] = email[:30]  # FIXME
user = User.objects.create_user(**params)

the email address can be up to 100 characters, but the authentication form only allows for 30 characters because it references the username field:

def get_authentication_form(self, **kwargs):
    return AuthenticationForm(**kwargs)

There should be a AuthenticationForm by default which has a max_length of 100 characters if this way of authenticating is used.

The current one tax per Price object method is very specific to certain regions of the world. I propose a more flexible tax calculation architecture that can be programmed to be compliant with more tax systems around the world.

Some background: I'm building a shop for use in Quebec, subject to local laws. The Quebec tax system uses calculates two taxes independently: the federal tax, GST, and the provincial tax, PST. These taxes are calculated on the order subtotal, and not per item (makes no difference if internal calculations use extra significant digits). Additionally, Quebec's PST used to be calculated on the subtotal plus the GST (effectively compounding the rate) but this is no longer the case. From my research, there are still places that compound the tax, such as Prince Edward Island. One more quirk: all this tax mess means the current rates in Quebec are 5.0% for the GST and 9.975% for the PST. Two decimal places are not enough to store the tax rate.

As such, I will attempt to write add a new TaxProcessor class to augment the current implementation. I plan to create a new setting PLATA_TAX_CLASS to be used the same way as PLATA_SHOP_PRODUCT, to decouple the actual tax model and allow a new model to be substituted.

While we're on the subject, why not rename those two settings to PLATA_TAX_MODEL and PLATA_PRODUCT_MODEL respectively? That would be clearer and more consistent, allowing future changes of this kind to follow a naming convention.

We're currently evaluating Plata for a multi-country shop that includes Switzerland, Germany and the US.

One thing I'm uncertain about is that US prices must include differing sales taxes depending on the location of the customer. That tax is not included in the price. In the European countries, the tax is fixed per-product and included in the price.

For our shop this means that we'd have to change PLATA_PRICE_INCLUDES_TAX per order, depending on the country version the customer is accessing. Since it's defined globally, is there a workaround for this case? I'm not very fluent in Plata yet so I might be trying to solve this the wrong way.

I thought about a pull request adding a method on "Shop" in this manner:

    def price_includes_tax(self, order=None):
        return settings.PLATA_PRICE_INCLUDES_TAX

This would recreate the current way of handling this issue. For our case, we'd return a value based on the currently set language or order.language_code. What do you think?

I need to charge VAT for customers inside the European Union.

How would I begin implementing this type of tax?

Hi there,

we recently added plata to our Django application and are using an existing database with South. We added plata to the INSTALLED_APPS list and called manage.py migrate for each application added to the list. We didn't use Django's syncdb command.

INSTALLED_APPS += (
    'plata',
    'plata.shop',
    'plata.contact',
    'plata.discount',
    'plata.payment',
    'plata.product',
)

The initial data script for "plata.shop" (0001_initial) fails, as it refers to "simple.Product" which does not exists:

FATAL ERROR - The following SQL query failed: ALTER TABLE "shop_orderitem" ADD CONSTRAINT "product_id_refs_id_790e3655" FOREIGN KEY ("product_id") REFERENCES "simple_product" ("id") DEFERRABLE INITIALLY DEFERRED;
The error was: relation "simple_product" does not exist

It seems that the initial South migration file uses a non existing app or has an old reference to the plata example app, that isn't part of the source distribution anymore. Therefore we used the following workaround to successfully migrate the whole plata application:

• Delete the plata.shop migration directory
• Call manage.py syncdb
• Copy the plata.shop migration directory back to the original path
• Call migrate --fake shop

Maybe you could modify the initial migration file, so that migrating Plata on an existing database without syncdb works.

Thanks in advance,
Henning

Hi,

If I have the settings as:

INSTALLED_APPS = (
    ...
    'plata.discount',
    'plata.payment',
    'plata.product',
    'plata.shop',
    ...

Then deleting orders fails:

In [1]: Order.objects.all().delete()
---------------------------------------------------------------------------
DatabaseError                             Traceback (most recent call last)
<ipython-input-1-2dbc0623de24> in <module>()
----> 1 Order.objects.all().delete()

/.../env/local/lib/python2.7/site-packages/django/db/models/query.pyc in delete(self)
    508 
    509         collector = Collector(using=del_query.db)
--> 510         collector.collect(del_query)
    511         collector.delete()
    512 

/.../env/local/lib/python2.7/site-packages/django/db/models/deletion.pyc in collect(self, objs, source, nullable, collect_related, source_attr, reverse_dependency)
    175                     if not sub_objs:
    176                         continue
--> 177                     field.rel.on_delete(self, field, sub_objs, self.using)
    178 
    179             # TODO This entire block is only needed as a special case to

/.../env/local/lib/python2.7/site-packages/django/db/models/deletion.pyc in CASCADE(collector, field, sub_objs, using)
     15 def CASCADE(collector, field, sub_objs, using):
     16     collector.collect(sub_objs, source=field.rel.to,
---> 17                       source_attr=field.name, nullable=field.null)
     18     if field.null and not connections[using].features.can_defer_constraint_checks:
     19         collector.add_field_update(field, None, sub_objs)

/.../env/local/lib/python2.7/site-packages/django/db/models/deletion.pyc in collect(self, objs, source, nullable, collect_related, source_attr, reverse_dependency)
    173                 else:
    174                     sub_objs = self.related_objects(related, new_objs)
--> 175                     if not sub_objs:
    176                         continue
    177                     field.rel.on_delete(self, field, sub_objs, self.using)

/.../env/local/lib/python2.7/site-packages/django/db/models/query.pyc in __nonzero__(self)
    128             return bool(self._result_cache)
    129         try:
--> 130             iter(self).next()
    131         except StopIteration:
    132             return False

/.../env/local/lib/python2.7/site-packages/django/db/models/query.pyc in _result_iter(self)
    116                 raise StopIteration
    117             if len(self._result_cache) <= pos:
--> 118                 self._fill_cache()
    119 
    120     def __nonzero__(self):

/.../env/local/lib/python2.7/site-packages/django/db/models/query.pyc in _fill_cache(self, num)
    873             try:
    874                 for i in range(num or ITER_CHUNK_SIZE):
--> 875                     self._result_cache.append(self._iter.next())
    876             except StopIteration:
    877                 self._iter = None

/.../env/local/lib/python2.7/site-packages/django/db/models/query.pyc in iterator(self)
    289             klass_info = get_klass_info(model, max_depth=max_depth,
    290                                         requested=requested, only_load=only_load)
--> 291         for row in compiler.results_iter():
    292             if fill_cache:
    293                 obj, _ = get_cached_row(row, index_start, db, klass_info,

/.../env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.pyc in results_iter(self)
    761         if self.query.select_for_update and transaction.is_managed(self.using):
    762             transaction.set_dirty(self.using)
--> 763         for rows in self.execute_sql(MULTI):
    764             for row in rows:
    765                 if resolve_columns:

/.../env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.pyc in execute_sql(self, result_type)
    816 
    817         cursor = self.connection.cursor()
--> 818         cursor.execute(sql, params)
    819 
    820         if not result_type:

/.../env/local/lib/python2.7/site-packages/django/db/backends/util.pyc in execute(self, sql, params)
     38         start = time()
     39         try:
---> 40             return self.cursor.execute(sql, params)
     41         finally:
     42             stop = time()

/.../env/local/lib/python2.7/site-packages/django/db/backends/sqlite3/base.pyc in execute(self, query, params)
    335         query = self.convert_query(query)
    336         try:
--> 337             return Database.Cursor.execute(self, query, params)
    338         except Database.IntegrityError, e:
    339             raise utils.IntegrityError, utils.IntegrityError(*tuple(e)), sys.exc_info()[2]

DatabaseError: no such table: stock_stocktransaction

If I add "plata.product.stock" to INSTALLED_APPS then deletion succeeds.

Hi Matthias,

this is only a small issue, but some models from plata.shop.models have unicode representation parts, that will not be translated. E.g. "of" in OrderItem.__unicode__:

def __unicode__(self):
        return u'%s of %s' % (self.quantity, self.product)

This will mostly affect only the admin backend, but it would be nice to have translation for the objects themselves, too. The following models seem to miss a gettext call:

• OrderItem
• OrderStatus
• OrderPayment

Just an idea. With kind regards
Henning

(rrr PK 5617 and 5618)

The determination of the order_id value in Order.save() is racy.

Hallo Zusammen

We have failed in putting the exaple project into run. With a virtualenv the requirements are uncomplete, it is missing xlwt and pdfdocument.

Once running I had this error:

DatabaseError at /reporting/product_xls/
no such table: stock_period

Beste Grǘße

Ich habe die Demo (example) mal getestet. Ging auch alles soweit, aber ich kann nie Produkte dem Warenkorb hinzufügen, da er immer sagt, dass es das Produkt nicht an Lager hat.

Lagerbestand bei Produkt habe ich aber auf 99999 gesetzt.

Was mache ich falsch?

Hi,
I am testing the checkout process with paypal module (sandbox). I've put may paypal address and 'false'. When paypal page returns me to the succes page there still is a "balance remaining", so the order is still "opened".
Am I doing something wrong?

Thanks.

add name, sku, price fields and fill them automatically in stocktransaction.save if possible

This is an issue that I ran into when switching from a SQLite back-end to a MySQL back-end with InnoDB engine. While this is a danger zone from both Django and South view points, it highlights an issue in Plata migrations that others might face as well.

The problem is this: the migrations were created with simple.Product as the product class. This creates a foreign-key constraint in product.stock.StockTransaction and shop.OrderItem model tables to simple.Product model table, like:

ALTER TABLE `stock_stocktransaction` ADD CONSTRAINT `product_id_refs_id_549808cd371cc71a` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`);

and

ALTER TABLE `shop_orderitem` ADD CONSTRAINT `product_id_refs_id_66f6c467790e3655` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`);"

Now, when a Plata user creates their own project, they will create their own product model, but creating either stock transaction record or order item record results in an integrity check error like:

IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_billing`.`shop_orderitem`, CONSTRAINT `product_id_refs_id_66f6c467790e3655` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`))')

The simplest work-around for this is for the developer to add new migrations for these models so that new foreign key constraints are generated:

./manage.py schemamigration plata.product.stock --auto
./manage.py schemamigration plata.shop --auto
./manage.py migrate

However, this may be problematic for users, who have Plata installed system-wide as South will, of course, attempt to create these migrations in site-packages Plata directories which a regular user doesn't have access to. Furthermore, distributing these migrations and applying them at deployment may be problematic.

A possible solution on Plata side may be to modify the migration scripts to not use simple.Product, but rather settings.PLATA_SHOP_PRODUCT so that the correct constraints are generated on the initial migration right away. This might still be problematic -- what should happen if the user changes their PLATA_SHOP_PRODUCT setting mid-project?

Since Python 2.6 provides the native 'json' module, would Plata be able to use that instead of enforcing the 'simplejson' dependency in environments that can use the native json module?

... and shorten the checkout process by one step

Hi.

I add to settings.py according to the instructions: http://www.feinheit.ch/media/labs/plata/installation.html

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'grappelli',
    'django.contrib.admin',

    'south',

    'vinny.apps.shop',

    'plata',
    'plata.contact', # Not strictly required (contact model can be exchanged)
    'plata.discount',
    'plata.payment',
    'plata.shop',
)

PLATA_SHOP_PRODUCT = 'vinny.apps.shop.models.Product'

And then I create the models in vinny.apps.shop.models.py:

# -*- coding:utf-8 -*-

from django.db import models
from django.utils.translation import ugettext_lazy as _

from plata.product.models import ProductBase
from plata.shop.models import PriceBase

class Product(ProductBase):
    name = models.CharField(_('name'), max_length=100)
    slug = models.SlugField(_('slug'), unique=True)
    description = models.TextField(_('description'), blank=True)

    class Meta:
        ordering = ['name']
        verbose_name = _('product')
        verbose_name_plural = _('products')

    def __unicode__(self):
        return self.name

    @models.permalink
    def get_absolute_url(self):
        return ('plata_product_detail', (), {'slug': self.slug})

class ProductPrice(PriceBase):
    product = models.ForeignKey(Product, verbose_name=_('product'),
        related_name='prices')

    class Meta:
        get_latest_by = 'id'
        ordering = ['-id']
        verbose_name = _('price')
        verbose_name_plural = _('prices')

When I run ./manage.py syncdb, I get an error:
Error: One or more models did not validate:
shop.orderitem: 'product' has a relation with model vinny.apps.shop.Product, which has either not been installed or is abstract.

Is it maybe possible to override the decimal fields so it can be limit to a standard of 4 digits and and 2 decimal? Its now rounding to an extreme amount of digits (14) wich is confusing in the backed for admins. Or do i have to override the processors to round it?

It should be possible to shorten the checkout process or even putting it on one page.