I’ve found an issue that I thought was easy to fix but then, when I analice it, it turned out to be pretty complex.
I need some insight and maybe some discussion about the possible solutions. Here is a link to the issue in GitHub with the description in the OP and the complexity analisys in the comments.
I think that it’s better to discuss here in Discuss than in GitHub.
Lets see what you think. I’d like to read opinions, information, thoughts. Maybe you have another solution that is not listed, I’d like to read it.
There are a lot of different directions you could go here, but I would largely caution changing the default behavior (consider it a breaking change/ major version difference perhaps). Perhaps exposing some settings for what’s copied over in Item Variant Settings?
Are you referring to this solution proposed in the GitHub issue??
- A checkbox in the variants for when the user don’t want to copy the
reorder_level child table of the template (this solution seems to be very specific but can be the more versatile)
I apologize, I was thinking that your problem was occurring when you duplicated an Item, so this is a tangent and not helpful: In the doctype (but its not customizable) there’s a “No Copy” option. Normally this sets what’s copied over when a new doctype is duplicated.
Yes, I think you’ll want to make some changes to the Item Variant Settings.
Alternatively (if you need it to be this granular), you can customize the Item (Master and Variant) to indicate if and what fields should be updated when the master is updated. The UX part of this is more difficult to solve.
I think that there is no necessity to make a field selector to determine what is going to be copied or not. I think that just this field (
reorder_level) is the problematic one.
Do you think that the checkbox in every variant is going to be enougth? Is it a good solution?
The checkbox is not going to be checked by default and the idea is to check it when you customize the variant
reorder_level. Then, when you save the template of the variant, if the variant has the box checked, then it does not update the
What do you think?
@Nahuel_Nso and I had a telegram call to talk through some of these issues. Basically we landed on most of a design to make the Item Variant Settings doctype as a more configurable extension for creating new Variant Items.
The first step would be changing Item Variant Settings from a Single to a regular doctype. Then adding a link field (shown only when
has_variants == true) that would allow the template to follow a specific mapping for creating or updating variants. When the Item template is updated, if the Item Variant Settings do not match, it would obey the settings field specified in the variant and not the template.
This design offers the maximum amount of configurability with a minimal addition to the UI. Since changes to the Item doctype are far-reaching and can have unintended consequences, I would think that it makes sense to talk it over with the maintainers.
Moving Item Variant Settings to a DocType that can be selected for different types of Item templates, seems like a reasonable approach, and a valid contribution.