It's OK to do this in this manner and not via for example the keyring, since we there's no actual user-name involved, only the machine-name -- anyone on the same machine is _already_ capable of sending the basically the exact same request that originated the access in the first place.
part of CURA-12708 (alt implementation)
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
If "T(\d*)" was "T(\n*)" it would search for newlines. There isn't
any such \d escape character.
It should be "T(\\d*)" or r"T(\d*)" going with the latter, to be
easier to read and be consistent with other Cura usage.
Start python with -Wd or for python 3.12 will raise a SyntaxWarning.
This might on one hand have (other) consequences, and given the slowness we encounter not even be enough in some cases (may be related to the size of the messages?) May need to be fixed on server side.
attempt to adress CURA-11956
printer names can be different for same type of printer.
Also, printer type is coming from cloud here so the type search is changed accordingly
CURA-11432
This was a mistake in the previous implementation. The relevant piece of code was adding ufp support for um3 printers. This is legacy support for this printer since the printer didn't know it supported ufp, but through the digital factory it could support ufp files. However, with the addition of method printers we should have added an additional check where we also check if the printer is an um3. Instead an additional check was added that did the same for makerbot printers. Because of this check didn't have a "is method" check support for makerbot format is also added to s-line printers and legacy um printers.
(fyi @saumyaj3)
CURA-11377
