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.
If the user that created a project has been deleted, the response from the API doesn't include a username. This crashes Cura because it had no default for the username.
The organization_shared field was also optional.
Done as a small fry to fix a bug found by a colleague.
It could happen if there are bugs in the cloud, e.g. if they strip special characters somewhere.
We'd want to know it if they do. But we also don't want Cura to crash if the remote connection is not reliable, or if there's changes/bugs in the future.
Fixes Sentry issue CURA-42F.
Had to implement this a bit differently as stated in the ticket. This field is returned when uploading the project file.
Logic needed a bit of a change as the new behavior dictates a sequence (we can only upload the print file after the project file is uploaded, and we know the correct `file_id`/`source_file_id`) where before these two api calls were done in parallel.
CURA-8555
Added a dictionary where additional user rights can be set.
A plugin such as the DigitalFactory can update this dictionary
if certain account rights change. The `account.additionalRights`
is intended to allow us some flexibility, without breaking the API
in the future.
The Application Switcher now queries the additional account rights,
which is updated by the DF plugin to only show `My printers`,
`Digital Library` and `Print jobs` when the user has access to the
DF.
Contributes to CURA-8624
Instead of relying on the filename emitted when the workspace is changed. This is done so the user can also change the project name when saving to an output device, such as a local file, or the digital library, that supports changeing the (file)name.
CURA-8358
When the `_onGetProjectsFirstPageFinished` is reached, the pagination manager already contains the correct pagination metadata and links, so calling `clear()` there resets them giving the impression that there is no next page.
This commit fixed that by calling the `clear()` function should when the search filter is applied, instead.
CURA-8009
When checking whether the user is allowed to create a new library project, we need to retrieve the **private** (aka non-shared) projects that are linked to the user's account. If the user has reached the maximum private projects, then they are no longer allowed to create new ones.
**Note**: We need to set the `pagination_manager` to `None` when doing this get request, or else the next/previous links of the pagination will become mixed up with the pagination links of the list of projects shown to the user, corrupting them and creating the wrong "get more projects" link.
CURA-8112
Instead of letting users go through the project creation process only to get rejected with a "subscription limits reached" message, now the "New Library project" button is being replaced with an "Upgrade plan" button when the maximum allowed projects have been reached for the specific amount. The button is accompanied by a tooltip that explains the situation to the user. Once clicked, the user is redirected to the subscriptions page.
CURA-8112
Most people should be able to type 5 characters per second. And those that can't will just have to see it refresh after every stroke.
Contributes to issue CURA-8009.
Otherwise when we refresh the project list after searching it would put the new results at the end. That's not what we want.
Contributes to issue CURA-8009.
This passes the filter on to the API call and causes the API call, so that we only get the projects that the user searched for.
Contributes to issue CURA-8009.
Seems to work fine.
The pyqtSignal is not technically necessary unless we display this filter in the interface anywhere. We don't currently. If the signal is not present it would complain about non-notifyable properties. And making it a slot instead of a signal seems a bit unintuitive to me in how the field is being used.
Contributes to issue CURA-8009.
Users with an account and an UM printer should have some basic access to the Digital Library. To this end, and to remain future proof, the online team has made an extension to its API so now feature budgets can be gauge. At the moment it's only checked wether the user has any access to personal projects at all. If so, the interface shows Digital Library functionality. Known issue: Removing the last printer from DF while still logged in leaves the DL access in the Cura interface until logged out or Cura restarted. Additionally, I think the response for a logged in user without any printer from the API is just 'data = empty list' instead of everything set to False and 0 (which should be the case as they're all listed as required fields in their docs ... maybe I'm missing something). In any case, the code as is now can handle that as well.
CURA-8138
