When the MachineNode is updated through _loadAll, it was not updating
its VariantNodes when they already existed. This caused an issue to
UM2+Olsson block printers, where changing the G-Code flavor to Marlin
was not updating the VariantNodes to search for materials (since the
variants already existed).
This commit fixes that by forcing an update to the existing Variant
nodes.
CURA-7354
I don't know what exactly caused this since it's impossible to trace. But the crash happened with a setting called 'dual_gcode' which currently doesn't exist in Cura. So I think it must be some plug-in that adds it. In any case, it's good to be defensive about this sort of thing. Good type checking would've caught this for us.
Fixes Sentry issue CURA-JB.
See CURA-3M in sentry. It most commonly happens with the anycubic,
since it had some weird stuff with it suddenly supporting materials.
This change will make it so that no crash happens. Old profiles will still have
an empty material. This isn't really an issue, since the interface will mark this
as an error (prompting users to switch).
The container registry was incorrectly being searched with a
variant_name == None, which always returned an empty printer-specific
materials list. As a result, the generic material settings were always
being loaded if there was no variant specifically indicated inside
the fdm_material file. The printer specific values were consistently
being ignored.
This commit fixes that by removing the search with a variant_name==None
which correctly returns the printer-specific materials list while
loading the materials from the variant nodes.
CURA-7087
The PrintInformation test wasn't cleaning up after itself correclty. This
left some stuff behind that the other tests were using. Since this is bad (as at that point
tests can influence other tests), i've fixed that
This should not happen, but we've seen some cases where it would cause a crash, usually
when a previous upgrade did something a bit weird (in this specific case; a printer
with an empty variant, whereas it should have a variant).
Since any change that the user will make will ensure that the variant is no longer empty (eg;
any selection of a variant will mean it's no longer empty) and that there is no way back,
it should be pretty safe to ignore the situation as it will resolve itself eventually
CURA-6992
This should not happen, but we've seen some cases where it would cause a crash, usually
when a previous upgrade did something a bit weird (in this specific case; a printer
with an empty variant, whereas it should have a variant).
Since any change that the user will make will ensure that the variant is no longer empty (eg;
any selection of a variant will mean it's no longer empty) and that there is no way back,
it should be pretty safe to ignore the situation as it will resolve itself eventually
CURA-6992
