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.
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.
> 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.
> 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
> On 06/08/2007, at 8:45 PM, cwells wrote:
> > 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.
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
On 8/6/07, Bruce Kroeze <bkro...@gmail.com> wrote:
> On 8/6/07, Itai Tavor <itai.ta...@gmail.com> wrote:
> > 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
> > On 06/08/2007, at 8:45 PM, cwells wrote:
> > > 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.
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.
On 8/6/07, Chris Moffitt <ch...@moffitts.net> wrote:
> 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
> On 8/6/07, 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:
> > On 8/6/07, Itai Tavor < itai.ta...@gmail.com> wrote:
> > > 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
> > > On 06/08/2007, at 8:45 PM, cwells wrote:
> > > > 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.
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.
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:
> On 8/6/07, Itai Tavor <itai.ta...@gmail.com> wrote:
> > 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
> > On 06/08/2007, at 8:45 PM, cwells wrote:
> > > 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.
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
On Aug 6, 10:34 am, "Chris Moffitt" <ch...@moffitts.net> wrote:
> 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.
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.
> 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
> On Aug 6, 10:34 am, "Chris Moffitt" <ch...@moffitts.net> wrote: > > 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.
- 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 ;)
> 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
> On Aug 6, 10:34 am, "Chris Moffitt" <ch...@moffitts.net> wrote: > > 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.
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:
> - 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.we...@gmail.com> wrote:
> > 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
> > On Aug 6, 10:34 am, "Chris Moffitt" <ch...@moffitts.net> wrote: > > > 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.
> 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
> > On 8/6/07, cwells <cliff.we...@gmail.com> wrote:
> > > 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
> > > On Aug 6, 10:34 am, "Chris Moffitt" <ch...@moffitts.net> wrote: > > > > 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.
