Display the correct default permissions when creating a share.
- The default displayed was not in sync with the server because
the client was setting permissions when creating a share while it
should get the default permissions from the server to display it to the
user first.
Stephan Beyer [Tue, 7 Jul 2020 07:10:48 +0000 (09:10 +0200)]
Make csync_file_stat_s::isE2eEncrypted a bitfield
This is in line with other bools of that struct and gets rid
of clang-tidy's modernize-use-default-member-init warning.
(The trivial alternative to get rid of that warning would be
to use default member init for that bool variable, but I think
it is better to have it as a bitfield.)
Stephan Beyer [Tue, 7 Jul 2020 06:51:05 +0000 (08:51 +0200)]
Filter clang-tidy output on Drone for errors
The run-clang-tidy is very verbose and prints a lot of unneccessary
information. This commit greps for errors in the output.
Moreover, we add the -quiet switch.
As a desired "side" effect, this commit repairs the issue of
run-clang-tidy-6.0 that it does not return a usable exit code.
Hence clang-tidy errors will lead to CI failures now.
Kevin Ottens [Wed, 8 Jul 2020 09:18:07 +0000 (11:18 +0200)]
Adjust to makeDbName returning an absolute path
PR #1451 changed the behavior of makeDbName which now returns an
absolute path. This obviously then failed in nextcloudcmd which
prepended to it the path to the local folder to sync. We just stop doing
this to have the journal db end up at the right place in that case as
well.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Mon, 6 Jul 2020 12:16:28 +0000 (14:16 +0200)]
Handle properly null avatar
If we try to produce the avatar before we managed to connect we'd end up
trying to paint in a null image. Just return early, which will allow the
caller to do something else instead.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Tue, 7 Jul 2020 14:50:31 +0000 (16:50 +0200)]
Decode the href from the XML payload
The XML we get as reply has href entities properly percent encoded.
Since we didn't go through QUrl next we didn't get a properly decoded
version. Make sure we decode it before storage.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Stephan Beyer [Mon, 6 Jul 2020 18:12:58 +0000 (20:12 +0200)]
Set maximum height of account and app menu
The menus may become too large if they have too many items
(the account menu has this in case of many accounts, the apps
menu in case of many apps). This commit limits the maximum
height such that the menus do not hide the header.
Kevin Ottens [Mon, 6 Jul 2020 12:44:23 +0000 (14:44 +0200)]
Reach out to the contentItem inside of the ListView to find the width
Turns out that the ListView embedded in the Menu (reachable via
contentItem) would create a binding loop if we're using its
childrenRect. But really we're interested in the total width for the
instantiated delegate *inside* the ListView. That's why we go one level
deeper and get the childrenRect of the inner contentItem instead.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Michael Schuster [Thu, 25 Jun 2020 14:59:57 +0000 (16:59 +0200)]
ConfigFile security: Migrate Proxy password to keychain
When specified in the config file, the Proxy password will be migrated
to the keychain, for backward compatibility and to allow admins to
overwrite an existing password by rolling out updated config files.
Once migrated to the keychain, the password will be removed from the
config file.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Michael Schuster [Wed, 24 Jun 2020 22:30:41 +0000 (00:30 +0200)]
Move QKeychain::NoBackendAvailable error handling to KeychainChunk class
Originally this was in the WebFlowCredentials class. Since we've abstracted everything
from there already, let's also move this in case some other code may use
KeychainChunk::ReadJob prior to WebFlowCredentials.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Kevin Ottens [Mon, 6 Jul 2020 11:55:14 +0000 (13:55 +0200)]
Fix the hover for the other menu items
Ultimately we would avoid the code duplication by creating our own
proper QQC2 style instead of directly tuning everything. That's a battle
for another time (more elements would need to be adjusted for that, I
don't want to dilute this branch too much).
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Thu, 2 Jul 2020 16:19:16 +0000 (18:19 +0200)]
Make sure moves involving e2e are delete + upload
If the file has a mangled name or will end up in a parent directory
known to be encrypted, we stick to the CSYNC_INTRUCTION_NEW instead of
going for CSYNC_INSTRUCTION_RENAME. This way we'll have a delete and an
upload instead of a move command.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Thu, 2 Jul 2020 14:22:48 +0000 (16:22 +0200)]
Move the e2e information fetch even earlier
We used to do it when the propagation starts, let's do it even before
the discovery starts. This way we'll have a chance to exploit the
information during the discovery phase.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Don't display quota information when the user has no quota.
- The code handling the api response was not up to date with the latest
api changes.
- Unlimited quota display: use qint64 to avoid data loss
- Change total with quota: total holds the quota total and not the storage total.
Camila [Mon, 29 Jun 2020 17:41:51 +0000 (19:41 +0200)]
Fix #2085 new tray menu.
Update systray behavior and context menu:
- left click brings up the new QtQuick based dialogs on all latforms
- right click brings up the new QtQuick based dialog on Mac OS only
- right click brings up a context menu on all other platforms than Mac OS
- "Quit Nextcloud" => "Exit Nextcloud"
- Add "Open main dialog" option.
Kevin Ottens [Wed, 1 Jul 2020 12:12:18 +0000 (14:12 +0200)]
Avoid job parallelism when uploading to an encrypted folder
With the current design of the file upload this necessarily pushed to a
lock starvation on the folder. Indeed you could end up with N jobs
asking for the lock at the same time. So just avoid parallelizing for
now even though it will be slow.
We could try to optimize but that'd require some serious changes to the
sync logic on the jobs... let's stabilize first and optimize later.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Tue, 30 Jun 2020 16:18:06 +0000 (18:18 +0200)]
Reduce interaction with e2ee folders when in the wizard
During the wizard we currently don't have much information about the
encrypted folders. In particular we can only display their mangled names
which is far from ideal for the user to make an informed choice.
That's why in the wizard we now forbid creation of subfolders in e2ee
folders and we also don't display subfolders of e2ee folders.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Tue, 30 Jun 2020 15:20:02 +0000 (17:20 +0200)]
Deal properly with encrypted item updates accross connections
In such cases we get a download for which _file is already the demangled
name and _encryptedFileName has the mangled information. This is
different to what we encountered so far where initially _file was
mangled and _encryptedFileName was empty. Let's deal with that case
properly.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Tue, 30 Jun 2020 08:24:40 +0000 (10:24 +0200)]
Also check on mangled names when cleaning up the journal
Otherwise, after a first sync all the mangled entries would be removed
from the journal. On second sync it would be fine because we'd then have
seen the unmangled names because of the local files. Unfortunately
that'd mean reuploading them for nothing or trying to mkdir again on the
server for nothing... with a chance of using differently mangled names
(although I didn't spot it, I can't exclude it never happened).
This also led to weirdly getting stuck during sync when there was more
than one sync point.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Mon, 29 Jun 2020 16:20:23 +0000 (18:20 +0200)]
Better separate between absolute and relative paths on downloads
I wish this would be all driven by the type system instead of
error-prone string concatenation everywhere. That will be for a (much)
later refactoring hopefully.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Fri, 26 Jun 2020 07:43:06 +0000 (09:43 +0200)]
Take care of mangled paths on download as well
This means adjusting PropagateDownloadEncrypted so that it knows where
the file will end (otherwise it would create temporary files in non
existant paths for instance).
In turn we have to adjust PropagateDownloadFile accordingly so that it
resolves the local folder the file will end up in.
And last we adjust PropagateLocalMkdir to resolve paths as well and
demangle as needed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Tue, 23 Jun 2020 16:13:20 +0000 (18:13 +0200)]
Assume that folder paths can be mangled
PropagateUploadEncrypted made the assumption of the folder names never
being mangled. This is not true since the previous commits so make sure
we properly deal with that using the journal db.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Thu, 18 Jun 2020 11:34:47 +0000 (13:34 +0200)]
Ensure GetFolderEncryptStatusJob gets all the folders
We ensure the PROPFIND Depth is infinity by explicitly specifying the
header (turns out our implementation just doesn't assume infinity
otherwise). This way we have a clear picture about *all* the folders of
the user, otherwise ClientSideEncryption couldn't be a trustable oracle
on the encryption state for any folder not on the root and all the
encryption code assumes it has a full picture of encryption.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Kevin Ottens [Wed, 17 Jun 2020 17:19:30 +0000 (19:19 +0200)]
Finally encrypt subdirectories during sync
We catch when a directory is inside a known encrypted folder and in such
a case we now do the following:
1) we encrypt the folder meta data (its name) properly and create it
under that mangled name on the server side
2) we mark the new folder itself as encrypted
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>