Confusion over ConfigurableProduct

[cwells]

I'm working on a site for selling T-shirts w/custom logos and am
evaluating Satchmo as a possible solution.

Anyway, I've added configurations for various sizes and colors. Each
t-shirt with a different logo is saved as a separate product.

The problem arises when I try to associate sizes/colors with a
product. I can add *one* variation (e.g., small, white), which duly
appears on the site. If I try to add a second variation (e.g. medium,
grey), I get the error "Product variation with this product already
exists". I'm pretty baffled at this point. How can I have multiple
sizes and colors for a product?

P.S. Unfortunately I wasn't able to try the demo store as load_data.py
failed with an IntegrityError when I tried to load the data (I'm using
psycopg2), so I wasn't able to inspect the demo.

Regards,
Cliff

[Itai Tavor]

Hi Cliff,

I can't say anything useful about your products problem, but I'd just
like to suggest that you use sqlite for running the demo store as
well as for your development... it's really easy to get it going, and
it removes a whole layer of potential problems.

HTH, Itai

[Bruce Kroeze]

Cliff, I just made a quick screencast explaining how to add product variations.  You can get to it here:

http://coderseye.com/files/satchmo

Enjoy and please let me know if it helps.

[Chris Moffitt]

Very cool.  We probably need to do more of these to make it clearer for folks how all this fits together.

I'm curious why you went this route versus using the "Create Variations" option on the Configurable Products page?  That would probably be a quicker process.

Also, if you didn't put in a price, then it's not going to show up properly in the store.

Does this make sense?

-Chris

[Bruce Kroeze]

Actually, I seem to have problems using the Create Variations option.  It doesn't seem to work at the moment, though it used to.  It creates a list of them at the bottom of the ConfigurableProduct page, but it doesn't actually add them to the database.

Beyond that, I don't like how (when it works) it forces every permutation and combination to be created.  It is a pain to delete invalid combos if you have any reasonably long list of options.  A wizard is badly needed, IMHO.

Good point about the price.  I was just going fast, and doing a fourth take didn't seem worth it.

[Chris Moffitt]

Agreed that we need a wizard or some way to make it much easier.  It's definitely high on my wish list.  I think we're just stuck trying to figure out how to do it and wanting to wait on the new-forms admin being integrated back into trunk.

The confusing thing is that the creation process is 2 step.  First, you associate your options, then save it.  Next time you edit it, chechk the "Create Variations" option and save it.  Then, it should create all the options.  The 2 step process is a django issue that I've never been able to work around.

-Chris

[cwells]

Wow, thanks. That's a big help.

It's clear why I was confused now: I didn't realize I had to manually
create a product for each variation (although that explains how I can
have different images for each variation, which was another question I
had).

Thanks again,
Cliff

On Aug 6, 9:39 am, "Bruce Kroeze" <bkro...@gmail.com> wrote:
> Cliff, I just made a quick screencast explaining how to add product
> variations. You can get to it here:
>
> http://coderseye.com/files/satchmo
>
> Enjoy and please let me know if it helps.
>

[cwells]

Actually what I find confusing (even after watching Bruce's
screencast) is having to set options on multiple products to achieve a
single goal. The current process is somewhat backwards from how a
user (assuming I'm anything like a normal user) would think about
it.

You have to:
1. Create a master product
2. Create sub-products (variations to-be)
3. Alter the master product to be configurable
4. Alter each sub-product to be a variation of the master

Frankly I had to watch Bruce's screencast at least four times (and
still embarrassingly couldn't memorize the process properly until I'd
gotten it wrong at least the same number of times).

The product variations are the particular point of pain. It doesn't
take much math to figure out that the example t-shirt store will
become quickly unmanageable. 5 sizes in 5 colors plus one "master"
results in 26 separate products, each of which has to be edited with a
multi-step process. At this point you have one "completed" product in
your store. A store with 100 products probably couldn't be managed
this way since it would require editing 2600 separate items.

I think what would help with overall confusion is to visually present
products that are variations as being distinct from normal or
configurable products (even if they are represented the same
internally). How they are represented internally isn't relevant to
the user. I'd suggest doing things like:
- getting rid of the option to add configurations to variations
- remove the category, description, etc from the product page for
variations since it doesn't appear they are ever used.

Possibly more complicated would be to reverse the process for how
variations are created. Rather than creating a dozen products and
then altering them to be variations, it would be much more convenient
to select all possible variations and then let the software create the
relevant products to match. Even if aspects of the variations
(price, number in stock, etc) had to be later edited, it would sure
beat adding them all by hand. Perhaps this is what "create
variations" is supposed to do, but I couldn't figure out how to make
it work (or perhaps, as Bruce mentioned, it's currently broken).

Anyway, I know this part is being refactored, but this is something
that should be considered during that process.

Regards,
Cliff

[Bruce Kroeze]

Thank you, this is exactly the sort of feedback we need.

To be honest, what I ended up doing for my site with a lot of products was to dump the file as YAML.  I then used macros in TextMate to create all my variations, finally stuffing the data back in with "loaddata".  Awkward and not something we can ask people to do in the real world.

[Chris Moffitt]

Try this and let me know if it is easier:

- From the admin interface, add a new individual Product
- Choose the appropriate Category, Name, etc.  for illustration purposes, I'm going to create a Satchmo Developer Book.  Also, put in a value for the price ($25.00) with no expiration or quantity.  Then click save.
- Now, you should see a list of all your products, click on the Satchmo Developer Book
- At the bottom of your screen, you'll see the option to "Add ConfigurableProduct"  click on the link
- Select the appropriate Option Group (Book Type) and click Save & Continue Editing
- Check "Create Variations" and Click the save button
 
You've now created all the Product Variants for the Satchmo Developer Handbook.  If you want to tweak specific ProductVariants you can but you don't have to.

If you follow this process, does it seem a little cleaner?

I realize it's still not optimal but want to make sure you've got the full flavor of options available to you.  Now, what feedback do you have ;)

-Chris

On 8/6/07, cwells <cliff...@gmail.com> wrote:

[cwells]

Procedurally, this sounds great. However, when I try it I get this
traceback consistently:

Traceback (most recent call last):

File "/var/www/virtual/twisty-designs.com/lib/python2.4/site-
packages/django/core/servers/basehttp.py", line 278, in run
self.result = application(self.environ, self.start_response)

File "/var/www/virtual/twisty-designs.com/lib/python2.4/site-
packages/django/core/servers/basehttp.py", line 620, in __call__
return self.application(environ, start_response)

File "/var/www/virtual/twisty-designs.com/lib/python2.4/site-
packages/django/core/handlers/wsgi.py", line 197, in __call__
dispatcher.send(signal=signals.request_finished)

File "/var/www/virtual/twisty-designs.com/lib/python2.4/site-
packages/django/dispatch/dispatcher.py", line 358, in send
sender=sender,

File "/var/www/virtual/twisty-designs.com/lib/python2.4/site-
packages/django/dispatch/robustapply.py", line 47, in robustApply
return receiver(*arguments, **named)

File "/var/www/virtual/twisty-designs.com/lib/python2.4/site-
packages/django/db/backends/postgresql_psycopg2/base.py", line 77, in
close
self.connection.close()

InterfaceError: connection already closed

I wonder if my problems stem from using the Django development server
or perhaps Django isn't well-tested on PostgreSQL.

Regards,
Cliff

On Aug 6, 2:56 pm, "Chris Moffitt" <ch...@moffitts.net> wrote:
> Try this and let me know if it is easier:
>
> - From the admin interface, add a new individual Product
> - Choose the appropriate Category, Name, etc. for illustration purposes,
> I'm going to create a Satchmo Developer Book. Also, put in a value for the
> price ($25.00) with no expiration or quantity. Then click save.
> - Now, you should see a list of all your products, click on the Satchmo
> Developer Book
> - At the bottom of your screen, you'll see the option to "Add
> ConfigurableProduct" click on the link
> - Select the appropriate Option Group (Book Type) and click Save & Continue
> Editing
> - Check "Create Variations" and Click the save button
>
> You've now created all the Product Variants for the Satchmo Developer
> Handbook. If you want to tweak specific ProductVariants you can but you
> don't have to.
>
> If you follow this process, does it seem a little cleaner?
>
> I realize it's still not optimal but want to make sure you've got the full
> flavor of options available to you. Now, what feedback do you have ;)
>
> -Chris
>

[Chris Moffitt]

Maybe this ticket is the issue -
http://www.satchmoproject.com/trac/ticket/96

If you apply the fix does that take care of the problem?

-Chris

[cwells]

This sounds like the culprit:

http://www.nabble.com/-Django-Code---5063:-PostgreSQL-connection-close-when-using-model-with-a-OneToOneField-and-a-ManyToManyField-t4210105.html

[cwells]

Outstanding! The patch worked and I'm liking this way a lot better.

Thanks!

On Aug 6, 6:18 pm, "Chris Moffitt" <ch...@moffitts.net> wrote:
> Maybe this ticket is the issue -http://www.satchmoproject.com/trac/ticket/96