2014-07-06 11:37 GMT+02:00 Guillem Barba Domingo <[email protected]>:
> 2014-07-05 17:14 GMT+02:00 Dale Scott <[email protected]>: > >> >> On Jul 5, 2014, at 7:30 AM, Cédric Krier <[email protected]> >> 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 > Recovering the original topic of thread, I think it could be useful (I don't know nor investigated if it is hard to implement) that the Template's attachments will be available from product form. -- Guillem Barba http://www.guillem.alcarrer.net
