There are really two types of errors that the HttpRequestManager can throw: Errors that it understands and errors that it doesn't understand. We must now intercept an error that it doesn't understand.
Contributes to issue CURA-7760.
This message is shown to the user in Cura when the digital
factory returns a 409, because the queue is full
CURA-7760 sending multiple printjobs notifications
If a cloud printer was connected, it would time out all the time. In some cases
it would do this in a single update loop (so connect and disconnect). Depending
on the machine of the user, this would either be visible or not at all.
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 reverts commit 28f4d8513db7efce17bfd8b80fa7c8b237fd1c18.
The original revert was to revert an accidental merge from master to 4.7. This now reverts the revert on Master, so that we still have those changes on Master.
Here are a number of improvements to the translated texts that make it easier for the translators to translate them:
* Never include layout elements such as <ul> or <li> in the translated text. The translators don't know what to do with them. Instead, leave the tags out of the translated parts and then wrap them around it in Python.
* If there are replacement keys in the source text, explain all of them in the context.
* Use a name within the brackets, to make it clear from context what the brackets mean and to disambiguate multiple keys if there are multiple.
* No invisible whitespace (such as space at the end of a line).
* Use plural forms with i18ncp if applicable (or i18np if no context is necessary).
I also changed the catalogue variable to lowercase with underscores, as per our code style.
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
Since the host_guid is unique to the printer, it is more reliable for
identifying the cloud printers. This comes in handy when the cloud
printer is removed from the account and re-added. With the host_guid,
the printer that is added again can be properly identified as an
existing Cura cloud printer, and be linked to the original. To
achieve that, the META_CLUSTER_ID of the printer is updated with the
new one that is generated when the printer is added again to the
account.
CURA-7505
The autosync, which happens every 30 seconds, will now also inform the
connection status when the get request succeeds or fails, which is an
indicator of whether the internet is reachable.
CURA-7492
This has to be done in order to avoid weird actions taking place, such
as the user pressing to remove the printers while another sync is
happening.
CURA-7454
After 30 seconds a new sync will be initiated, which will alter the
conents of self.reported_device_ids, thus making the current message
deprecated. Therefore, it is best to have a maximum lifetime of 30
seconds.
CURA-7454
When the "Printers removed from account" message pops up, it will give
the option to the user to remove all the printers that are not linked
to his/her account from Cura. Since this action removes all
configurations, it first pops a confirmation question box, and if the
user insists, these printers are purged from Cura.
Note: In order to properly delete all the files, the printers have to
be activated first before they are removed, or else some extruder
files in %appdata%/cura/<version>/user and %appdata%/cura/<version>/
extruders remain.
CURA-7454
