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>
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>
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>
When the ClientSideEncryption object is fed, also serialize the
encryption info of the folders inside the metadata table.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This will allow to exploit the information of a directory being
encrypted or not during the discovery phase.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This will turn useful for other consumers of that data. The alternative
would be to expose a method breaking all form of encapsulation.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
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>
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>
Since the e2e oracle works only in term of absolute remote paths and
that our model x._path was relative, we need to properly convert.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
Otherwise on second sync we wouldn't find anything under a mangled path
and just end up thinking said files were removed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
Yes... I still wish this would be all driven by the type system, would be
much less error-prone.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
It turns out this job expected an absolute remote path even in the case
of a subfolder sync point.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This was half broken before that commit and the previous one since some
of the categories would not be captured.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise it was a bit confusing and annoying for filter rules:
e.g. "nextcloud.sync.*" vs "sync.*".
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
We give them a parent to make sure they will be destroyed when the jobs
which created them are destroyed themselves.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
This is not only a question of performances in our case (complexity
being better on look ups). It also provides a few more services.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
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>
It was assuming we'd encrypt only files but directory names also need to
be encrypted. We just skip the writing to temp file part in that case.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This way this whole logic isn't stuck into the settings dialog anymore.
Also cleaned up the unused "decrypt folder" logic.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This is a much better place than the GUI, this way we ensure the
propagator is always operating of up to date information. Previously if
the propagator kicked in without user interaction from startup (not
showing the settings dialog) it would have no E2E information available
whatsoever... unsurprisingly it would thus take wrong information at
every turn.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Since we want to move to a place where the encryption of subfolders is
always enforced it makes no sense to leave it in control of the user.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Using a reference capture is a disaster waiting to happen here, if for
some reason we'd move from exec() to popup() for the menu below we'd be
getting garbage in the lambda call.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Previously we were showing up the settings dialog but it doesn't quite
make sense anymore now that we got two dialogs.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Note this won't work on all platforms. KDE Plasma and GNOME Shell (with
systray extension) assume that right click is necessarily for a context
menu exposed via D-Bus, there's not nice way to make the right click
popup the main dialog on those platforms.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We were calling accountState() on a "folder" member which could be
nullptr. In fact this would happen any time one right click on a file
outside of a sync dir under Windows, this thus led to a crash.
Since the capabilities variable was unused anyway, we just removed it.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We then get more items clickable, in particular the bottom one proposing
to open the activity application. Now we can click it and it opens the
activity application straight away.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This led to blurry icons. Now use a fixed size of 32 which also makes
them a bit more pleasing... at least to me. ;-)
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
For the "Activity" type activities, displayPath contains the file name
which is also in the subject. This was redundant, so now we don't
display an info line at all for that type of activities.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This leads to simplifying the computation code quite a bit as well.
Indeed we're separating concern between what is window size dependent or
not and that shows.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This was leading to the same logic being duplicated several times. It's
fine to return the QScreen* on the QML side directly but wrapped into a
QVariant.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The API is just more convenient there, the rect and point types on the
QML side are just pale shadow of their C++ counterparts.
Also improved a bit the constness of the Systray class.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The top left corner of that screenRect is (0,0) or based on
(virtualX,virtualY) depending on the platform. This leads to easier
reduction in code duplication.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This also fixes a couple of warnings at places (out of order init for
instance) and a potential bug in the webflow credentials / qtkeychain
integration.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This should address Tobias' concerns regarding the icon being
misleading. Now we basically do the following inside an encrypted folder
parent:
* encrypted folders get the encrypted icon;
* non-encrypted empty folders get the regular folder icon;
* non-encrypted non-empty folders get the broken encryption icon.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
I think I got the if clause wrong regarding limiting the command only to
member users. Let's move this out of the way for now.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This should pass, with the minimal .clang-tidy which was provided. Other
PRs should be done to enable further checks.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This test was failing locally for me. Indeed, through QStandardPaths it
was finding the user settings of my production client and not having the
initial state it expected. Using QStandardPaths test mode then it starts
from a clean slate every time.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
