Open atanisoft opened 4 weeks ago
Wouldn't it be better to define this on a per parameter basis then? I.e. in parameters.yaml
?
Something like a _assign
setting, with always
(default, current behavior), optional
(assign if available, ignore if not) and never
(create, but ignore this parameter). We could even add a 4th manual
setting, which forces setting the parameter manually if in interactive
mode (not sure if that'd get too confusing though).
Optionally the tool could dump a list of parts that have optional parameters that could not be resolved (similar to the current incomplete import but calling it out for optional parameters).
Imo, if they are already marked optional, you shouldn't get a warning if they aren't set ... because that's like .. the whole point.
Wouldn't it be better to define this on a per parameter basis then? I.e. in
parameters.yaml
?
You are probably right on that, it would mean potentially less updates to declare a single parameter name as optional / ignoreable there rather than in the categories.yaml.
if they are already marked optional, you shouldn't get a warning if they aren't set
Fair point, consider that part dropped.
In some cases users will have the KiCad integration enabled on the Inventree side and have virtual parameters defined on parts for such usages. If we do not declare these as part of categories.yaml then we get a warning for mismatch, if we do define it in categories.yaml then we are subjected to prompting (default behavior) when the value can not be determined automatically.
It would be ideal if we could declare the category as:
Or similar notation that would allow defining of a parameter on the parts to collect if found but skipped when not found. The parameter should still be created on the relevant parts regardless of a value being assigned during import. Optionally the tool could dump a list of parts that have optional parameters that could not be resolved (similar to the current incomplete import but calling it out for optional parameters).