First use of 3.11's StrEnum in the code base I think -- anyway, Python autoboxes these (maybe even the old str,enum things as well, but irrelevant now), so there's nothing in the way of making this an enum and have type-_checking_ instead of type-_o_'s.
done as part of CURA-12624
Otherwise if the server (on the printer) gives back something that can be parsed into JSON, but _isn't_ the authorization digest info, the thing breaks.
part of CURA-12624
New rules means we have to put printjobs and such behind a little authentication, as these contain personally identifiable info. These two effected calls where found _outside_ of the API class where I thought to be able to fix it 100%. See also the TODO's in the neighbourhood -- but I'm not sure I can just do what those say (move the relevant methods to the API), as those methods to be moved are _inside_ the larger Cura SDK (and they're public) and the place where I'm meant to move them to (the ClusterAPIClient) is _not_ (as they're in a plugin).
part of CURA-12624
The new regulations make a decent amount of sense -- but just because we agree with them doesn't mean we'd implemented this yet. Anyway, information wich can be used to personally identify people should be kept behind (virtual) locks and bars. The new firmware will only allow certain operations _after_ a request has been made to the .../auth/request endpoint, and someone in the physical vicinity (of the printer) has pressed ALLOW on a popup (with the application and name of the requester shown, on the printers' UI). After that, _as long as you put the relevant Authorization Digest in your HTTP headers_ (and use at least SHA-256), you may proceed to make other requests without the printer-server flipping out with a FORBIDDEN error.
The current commit _should_ also still work with printers that still have old (well, current I guess...) firmware -- but I didn't test that yet.
CURA-12624
This way, any new printer types we define will automatically get these properties that are used by the monitor stage anyway.
Contributes to issue CURA-9220.
This property was defined for Cloud printers, but not for Network printers. In QML this then resulted in an error saying that null cannot be assigned to a bool (for the 'visible' property). The visible property then defaulted to its default, true. And so it was always visible, but still had an error.
The error is now solved so that I can also check for other properties in this visible check.
Contributes to issue CURA-9220.
With the Qt6 upgrade, we have to treat enums as full enums, within their normal class namespace and such. They are no longer just integer-globals static in the QtCore.Qt class. They are no longer treated as integers by PyQt.
Other places that checked for such errors were already doing it like this.
Contributes to issue CURA-9100.
It seems that due to the threaded nature, the limit to the number of open file handlers could be reached here. Or it could just be locked or something of course.
Fixes Sentry issue CURA-2V2.
Some ultimakers tend to choke if you try and send a lot of materials in one go.
Previously we would also always send the materials on the main thread, which would also make
the interface freeze a bit. That should no longer happen.
The implementation of this is not really great, but since this is a hotfix i've opted to change
as little as possible.
CURA-8224
The code is clearly written to take into account that 'addresses' may be null. But not that the whole 'addresses' attribute may not exist. And then instead of printing one warning (Could not get information about XX) it instead printed a stacktrace and retried and printed a stacktrace and retried and printed a stacktrace and.... It ended up driving me a bit nuts when looking at the logs for unrelated reasons. So Ifinallay fixed it. Could end up as a speedup in some cases as well I suppose?
This could happen because a material is deleted right at that moment, since the SendMaterialJob is done on a separate thread.
Fixes Sentry issue CURA-JZ.
