2014-07-05 17:14 GMT+02:00 Dale Scott <dalesc...@shaw.ca>: > > >> On Jul 5, 2014, at 7:30 AM, Cédric Krier <cedric.kr...@b2ck.com> wrote: > >> > >> On 05 Jul 14:38, Axel Braun wrote: > >> Believe me, we did, and came around exactly that problem. > > > > You always seem to not know at all Tryton. > > For sure that's me, I'm trying to learn fast! ;-) > > Thanks everyone for your opinions. If I understand correctly, it seems the > variation functionality applies best in cases of "simple" differences that > do not affect price (selling S/M/L t-shirt example) or do not trigger other > changes (counter-example of car requiring larger generator for climate > control variation). > > If this model does not fit the situation, one can always a) use multiple > products and ignore the variation functionality, or b) customize code as > needed for the specific situation. That seems fair. >
Exactly. It's very common to don't require to work with different variants. With this use case the current UX is not the best, but it is a good solution to have the same base code supporting variants and no variants. The current design allow to get any Template's field from product in the code. If you have a product.variant instance "variant", you can't have a code that takes the "name" field from it and it will return the template's name transparently: product_name = variant.name If some module moves the field to variant to have different names per each variant, the above code will work taking the variant specific code. It is possible because the base module is designed with variants, but with the minimum variant specific data to allow other modules put in variant exactly the required fields. To improve the UX for only one variant use case more modules are required: Tryton is a framework. "Off topic" Available contrib modules: We made the product_variant_unique [1] module that force only one variant per template (only for templates configured as "Unique variant" wich could be configured as default value for new templates). It also adds a functional searchable field to template to have the variant code to template, so the Template's views are complete. Finally, it moves the wizards and related actions of product.variant to product.product. With these changes, user doesn't need to use the "Variants" menu entry for anything for unique variants products. An interesting improvement could be that the template's form would be shown instead of the variants form when the product is "unique variant. It would improve the UX when a product is open from Many2One field (in sale.line, for example). [1] https://bitbucket.org/nantic/trytond-product_variant_unique -- Guillem Barba http://www.guillem.alcarrer.net
