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.
Save some settings Cura doesn't use, but other consumers of the file might in the metadata during deserilization, so they can be properly re-serialized whenever exported.
part of CURA-9432
We don't want to create actual settings for all of these. Just store them in the profile metadata and restore them.
Serialising and deserialising these is a bit more work than what I could do now in 5 minutes so we'll have to do that a bit later, but at least for now we have the complete list.
Contributes to issue CURA-9432.
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.
Several reasons:
* It's bad style, making it harder to test with mocked PluginRegistry since all sorts of objects have copies of the un-mocked object in their fields.
* It's causing errors in this case when checkIfRestartNeeded is called before show().
Fixes Sentry issue CURA-3P6.
Let's put it in the Cura directory with the rest of such files, as to not muddy the 3MF file with all sorts of directories that are not known to other consumers.
Contributes to issue CURA-9413.
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
Swapped the loading order of Marketplace extensions so SyncOrchestractor is not fetched by PluginRegistry.getInstance().getPluginObject("Marketplace") in WorkspaceDialog.
CURA-8610
The solution here is to check first if a material file is inside "secure_paths" (these are install directory resource paths). If it is, it must be a bundled material.
CURA-8610
This adds a new function to the API of the Marketplace plug-in.
It's not pretty, but it's going to be how it is for a while.
Done to fix a critical build issue. The 'import plugins' thing works from source but not on the build.
When running from source, 'import plugins' works since it's working from the directory where the plug-ins directory is located. However in a build this doesn't work since the source code is in a different location there.
This provides control over how the header (the header is newly introduced in this commit) and footer components are rendered. The footer is the area where the `leftButtoons` and `rightButtons` are rendered. Having control over how this is rendered introduces for instance the possibility to render the buttons within a warning area (an example of this can bee seen in the WorkspaceDialog).
CURA-6990
