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
This was due to the connect function not being called on the CloudOutputDevice used to print on the cloud. This function is only called when it becomes an active printer (AbstractCloudOutputDevice is the active printer instead now).
The fix is to always listen for signals to reset the print job even when not the active printer.
I've chosen different signals now so there is not too much spam on the reset function.
The BackendStateDone signal catches new slices. The SceneChanged signal catches ufp files being loaded (These do not trigger BackendState changes)
CURA-9678
Move status check into _parseResponse
Don't give PrintJobUploadSuccessMessage() if printis awaiting approval. The print has successfully uploaded but it is pending approval instead so it does not make sense to display both messages.
CURA-9221
We'd assume so, but there is a permissions node for it. If it can't be read by the user, they can't navigate to the printer's overview page. So we should hide the button then.
Contributes to issue CURA-9220.
When using the visibility of the progress bar to detect if a job is already being sent, then make actually sure the progress bar is visible the moment the job starts, not at some unspecified time later in a method that might not even trigger if there is already a mesh ... so it's unlikely to even work, since the thing it was intended to prevent _very_ likely has the same mesh anyway.
CURA-8004
One of the reasons this bug (see parent of this commit ... or the issue nr if you have internal access) was so vague is that A. the user was insufficiently prompted, and B. no one could find anything in our logs.
CURA-8004
Since we use that to detect when the mesh is already uploaded, and thus can be reprinted, this could cause problems, since, while we do properly set it to None when an error is returned, if the request never returns to us, or if a reprint is started while the mesh is still uploading, the print-job cache could be set while the mesh wasn't actually there yet. Which could in theory have maybe caused the problems we see.
CURA-8004
This will now result in a job being put in the queue but not automatically printing, but there is at least a workaround for that.
Fixes Sentry issue CURA-14A.
This makes the cluster size also available when the machine is offline.
Also fixes an issue where the cluster size is improperly restored
once the internet connection comes back online, resulting in the printer
showing as a single printer until next sync
CURA-7347
