This old function is only necessary for upgrading from before v3.4. Best not let it crash in any other case, even if that would sometimes make very old machine instances corrupt if I made a mistake in thinking here.
Fixes Sentry issue CURA-3XG.
Add function to fetch package_id using only information from XmlMaterialProfile material container.
The only piece of information associating the material container and the package together is the file_name. To find the package that owns a material we have to search each of the material package paths.
It would be great to find a cleaner solution (preferable one that doesn't require invalidating the cached containers).
CURA-8610
The reasoning of PP-86 also holds for the support interface layers, however we forgot about support when we implemented PP-86. When doing PP-108 we found this improvement.
This was a bit more tricky then it at first seemed, since the information wether this is a 'secure version' comes from the user-application and is not known in the Uranium library. This is not normally such a point, but both the theme and the preferences objects are loaded _very_ early in the process, and that information needs to be injected before then. (Well, in the case of the Theme object it's less important, since in the implementation choseen that is now security wise at least only in charge of wheter or not to even show the theme as selectable in the interface, so that it only needs to be aware of the 'security' status any time before the user can see a preference screen, but not nescesarily earlier.)
SEC-255 | CURA-8966
If readJSON fails, it puts an entry in the log and then returns None. This then crashes with a TypeError because you can't check for things to be in None.
Fixes Sentry issue CURA-3V5.
VORON V2.4 is an fast machine. There is no reason to limit
the user to 300mm/s. Unlock these speeds by removing maximum_value
which makes cura fallback to machine_max_feedrate_x/y which are
set to the C (299,792,458).
Warning stays at 501 after Fulg talked with some VORON
team members they have come to the conclusion that
501 is fine as people start hitting issues on the machine
around the 500-600 range
Signed-off-by: Martin Botka <martin.botka@somainline.org>
