The position argument metadata always be there. However if it's not (because the file is old, or manually modified, or a version upgrade worked incorrectly, or whatever) then we shouldn't crash. We just don't know how to order it correctly then. This tries to repair it as best it can.
For instance if the file name is too long for this file system, if the computer is running out of disk space or if there is a general failure to write here.
Fixes Sentry issue CURA-YQ.
* Don't pre-load engine before other plug-ins
This was a fix for the post-processing plug-in that's no longer required.
It was also only applied when running from source, so obviously it's not required or we'd have seen it in the builds.
* Run automated tests in parallel
Done during Turbo Testing and Tooling.
* Pass number of processors via ctest command itself
More reliable apparently because it's a CMake variable that doesn't get cached. It shouldn't get cached or set in the CMake script because it's not the same for every computer.
Done during Turbo Testing and Tooling.
This was a fix for the post-processing plug-in that's no longer required.
It was also only applied when running from source, so obviously it's not required or we'd have seen it in the builds.
The stacks would get marked dirty for setting some metadata, but since thats
part of their construction, they aren't really dirty.
Previously, every single stack that was loaded would be marked as dirty, which causes unneeded
saving.
Basically we should never be raising the master Exception class, really.
The enclosing class has error handling in case this returns None already, so this fix is easy.
Contributes to Sentry issue CURA-Y5.
When printers share the same group_id, they are removed, regardless if
they are hidden or not. This was resulting in sometimes removing
multiple printers when removing a printer that was created by a project
file.
This PR fixes that by actually checking whether the printer to be
removed is hidden.
CURA-7522
Even though the metadata of the machine was updated when it was
rediscovered, the new cluster id was not updated in all its references
(such as in the _remote_clusters and in the _um_cloud_printers dicts).
This commit fixes that issue by properly updating all the entries
that depend on the machine's cluster id.
CURA-7505
to "Account synced"
Don't think the duplication I found is necessary, but I don't dare to
deduplicate it as I found some logic inconsistencies
CURA-7418
