Merge products / variants into one database table (one view / one list)

[edbo]

@pokoli

Normally I recommend opening to the “Products” option to directly create the template and a variant (which is implicitly created by default)

That’s also what I tell them to do. But then the fun begins and they start asking about the difference etc. For example why is list_price on the template and cost_price on the variant? Shouldn’t this be swapped? It turns out that sometimes variants also can have different list_price and cost_price. How are those going to be managed in the current situation?

@pokoli

but only if we move the product template to a separate module which is only activated when the database requires products and variants

That’s what I meant. Eventually make Template and Variant separate modules.

@ced

We will always need the current design. We must be able to define those properties at both level.

@pokoli

the new module will be responsible of creating the template with all the fields to be reused and add the template on the product.product.

For me the a template will not be more than a set of fields with a value or values. The field is taken from the product.product table by the user and a value is added to it. I was thinking of storing this data in a Dict with the field name as the key. Extra information like ‘required’ or ‘blocked by template’ etc can also be added. When a new product is created the user can add the template which then fills the different fields based on the data in the template. Creating templates can also be restricted to a group, so a predefined set of templates is available for the user.

The idea is kind of the same as for product attributes.

Variants can have a same kind of design, but I haven’t thought that through very well yet. Because variants are actual products.

@ced

I do not see the real benefit but I see a lot of drawbacks (migration, complexity, duplicate data etc).

I think that complexity will decrease because of just one place where the actual product data lives. This makes is for module owner easier to create a module which extends products. You only have duplicate data for the values you want to add to a new product based on the template. You can ask yourself if that’s duplicate data.

But for me, the real benefit is that new users can adapt Tryton much easier because it makes Tryton more straightforward. Also users who don’t use Tryton much often (say twice a year they do something with products and they open the client once a month) don’t have to fight anymore with the product. I’m seeing this in reality. They have no problem with sales or invoices, but they always complain about products.

The design also follows the rest of Tryton like sale / purchase / invoice. They all have one list and view where users can do their work.