| Age | Commit message (Collapse) | Author |
|---|
|
Since we're no longer running from `master` branch
It is more fitting to rename it to either dev or
main. This version is only used when running from
source when the CURA_VERSION variable isn't set
while performing the `conan install`
Contributes to CURA-9365
|
|
Restoring plugins will casue a headache when (they are large and) the central storage was removed in the mean time. Since it's current policy to ignore plugins _anyway_ when backing up, the simple solution is to also just don't restore them, even if they where present to begin with. Of course this is also applied to other to-be-ignored files and folder types.
should 'fix' CURA-8666
|
|
Seems to happen when there's files in there with badly-encoded characters in the file names.
Fixes Sentry issue CURA-2S7.
|
|
The file may not exist. In fact, that may be the whole reason why people want to restore a back-up. Try it, and give an error if it fails.
Fixes Sentry issue CURA-2QT.
|
|
Contributes to CURA-8418
|
|
CURA-8418
|
|
We decided to add the warning message in a separate ticket for 4.11.
This reverts commit 584a387debec75023094db6cba84a8bf1781d6ea.
|
|
We now allow the backup to fail gracefully when partial files
fail to be restored. But the user is not actively informed by
these failures. Leaving him/her unaware of the state of his
configuration folder.
This commit show's a message windows, listing the failed files.
Due to a string freeze at the moment we reuse the following i18n
message:
> The following error occurred while trying to restore a Cura backup:
followed by a list of files that fails to be restored.
Which is not ideal, but a sufficient warning in my opinion. At least
better then being completely uninformed.
Contributes to CURA-8313
|
|
Sometimes, while a backup is being restore, one of the files in the current config folder may be still in use. This means that once the backup tries to replace this file with the one in the backup, the entire backup restoration fails and half the configuration folder has been messed up.
To prevent that, we decided to ignore files that are currently in use while restoring a backup. This _may_ lead to a slightly wrong configuration (e.g. a plugin may not be restored properly), but it is an acceptable result, as the rest of the configuration folder is restored properly.
CURA-8313
|
|
To prevent the UI from being frozen. This way, the user knows that something is happening in the background and Cura didn't just stop working.
CURA-8313
|
|
Before calling the illuminate, we need to make sure that the previous cached Preferences have been overridden by the newly restored preferences from the backup. Otherwise, the `illuminate()` function will bring back the cached preferences and the new ones from the backup will be lost.
CURA-8313
|
|
CURA-8313
|
|
Because we're adding a messgae for the user if the loading of a plugin failed
(which can happen after backing up a plugin in central storage), we can re-enable
the backing up of plugins again.
CURA-8313
|
|
There were some cases where issues could occur due to plugins no longer being there
CURA-8313
|
|
This would've gone so wrong if we actually released 4.10 without this, since, as a string, 4.10 is 'smaller than' 4.6 (for example), because alphanumerical-order.
done as part of CURA-8269
|
|
CURA-8269
|
|
Backups are synced with your account anyway. Backing up the plugins means that you
quickly reach the limit of the max size (250mb) that the backups allow.
CURA-8269
|
|
Fixes sentry issue CURA-24R
|
|
CURA-7180 keyring storage
|
|
The server gives an error about this and we got complaints about it. As far as we know this can only happen when users mess with their profile folders. Still, it's good to not send -1. The original implementation of this is indeed very naive, but we don't have the resources to refactor that now.
|
|
For instance if the file name is too long for this file system, if the computer is running out of disk space or if there is a general failure to write here.
Fixes Sentry issue CURA-YQ.
|
|
|
|
Converted doxygen style comments to reStructuredText style in the files
found in Cura/cura/Backup directory recursively using the script
dox_2_rst.py (provided in the Uranium repo). Comments were manually
checked and changed if needed.
|
|
part of CURA-7325
|
|
part of CURA-7325
|
|
Prevent unpacking of possibly spoofed backups (as a last line of defence if other security has failed).
Zips with partially known content are a lot harder to spoof.
Thanks WhiteHats :-)
|
|
Also add a bit of logging so that we know what / how it went wrong
|
|
|
|
CURA-6471
|
|
CURA-5983
|
|
If the backup file didn't exist but the original did, then apparently they are not the same file so the copy should be allowed.
|
|
This crashes Cura on start-up for some people.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
cura/Backups/Backup.py
cura/Settings/ExtruderManager.py
cura/Settings/MachineManager.py
|
|
Like the rest of Cura and Uranium.
|
|
|
|
|
|
|
|
- Move AutoSave out of the plugins. It's a built-in module now.
- Add enable/disable saving data on CuraApplication.
- Avoid saving data in backup restore
|
|
|
|
|
|
|
|
|
