This change triggers a cascade of updates and in some cases triggers a sync. The sync trigger also triggers an update of the account permissions which crashes because the HttpRequestManager can't be started on a thread. We shouldn't make HTTP requests from our tests anyway so mock this away.
Contributes to issue CURA-9220.
Changing the log-in state causes additional requests to be made to get information from the account. Previously this wasn't a problem because the information was only obtained from other classes such as the DigitalLibrary to get information on how many library projects the user can make. But now that there are triggers in the Account class itself, those triggers get triggered. It'd make additional requests to the account server. We don't want the tests to make such requests.
Contributes to issue CURA-9220.
It is replaced by the new permissions system. The rights are more specific than 'digital factory access, yes or no'. It's now about whether you can read/write printers/projects/print jobs/etc and can differ whether it is your own project/job/etc or someone else's.
Contributes to issue CURA-9220.
These functions require special permissions in the account now. Just checking for digital factory access is no longer enough.
Contributes to issue CURA-9220.
If the user is not allowed to write profiles to the printers, then they'd get errors when trying to sync. Instead we'll redirect them to the USB workflow.
This also works for users that have accounts but don't have the printers in the cloud. The original requirements suggest that the entire sync button must be hidden for this case. But to allow those people to still sync via USB I'm opting for this solution instead.
Contributes to issue CURA-9220.
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.
It will likely be empty for guest accounts on networks where the administrator is the only one with rights to access other people's prints.
Contributes to issue CURA-9220.
According to the Account API, is this print job made by the same user?
This property is a bit inaccurate, in that this matches by the user name. The user name might be duplicate in some systems.
Contributes to issue CURA-9220.
If there are no permissions, this would result in an error and a supposedly empty queue. That's incorrect. It should make it more clear that the user has no permissions to view the queue, while appearing that it is the normal workflow (it is for that user). So hide the queue entirely, just like with the UM2+C.
Contributes to issue CURA-9220.
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.
