the file being locked may have been changed sinc the client synced it
so the server side file may have a modified etag. In such cases we do
not want to lock the file and would rather sync the nex server changes
before being able to lock the file
that would ensure that on client side the file being locked is matching
teh state of teh file on server side and would prevent inadvertently
overriding server changes
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
remove any commands related to publi share links because they either got
replaced by the use of the share dialog or are better achieved by
showing the share dialog
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
a file can be unlocked when:
* the lock is an user lock from the current user
* the lock is a token lock from the current desktop files client
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
in the contextual menu shown in files explorer will show encrypt menu
entry only for top folders that are non-encrypted and empty
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
with current end-to-end encryption only top folders can be encrypted
limit the availability of the menu entry to top folders
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
when receiving a shell integration socket command for ENCRYPT, a generic
interface and generic code paths was used
the assumption was that the listener socket would need (and remain)
valid while hanlding teh request
some code paths need to display error messages to the user via a
QMessageBox
the issue is that this will execute a Qt event loop that will handle the
socket disconnection while the socket variable from the caller seems it
will stay valid and alive
prevent that by not using a blocking method invocation such that life
time mishandling about the socket listener is not possible
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
may need the user to wait a bit longer but should prevent missing the
context menu
should still be robust since we only wait indefinitely if desktop client
sent a first reply
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
This is necessary in Wayland sessions for the clipboard related actions
of the socketapi to work. Indeed, QClipboard does its job only if we got
a window with the focus in such session.
In the case of the socketapi, it is generally the file manager asking
the desktop client to put something in the clipboard. At this point in
time no window of the client have the focus, so nothing gets added to
the clipboard.
KSystemClipboard on the other hand, uses the wlr data control protocol
under wayland sessions ensuring something ends up in the clipboard as
expected. When not in a wayland session it falls back to QClipboard so
no behavior is lost.
Signed-off-by: Kevin Ottens <ervin@kde.org>
those log lines can easily be skipped from info level as they are needed
in very rare occasion
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
ran
run-clang-tidy-14.py -header-filter='.*' -checks='-*,cppcoreguidelines-pro-type-static-cast-downcast' -fix
this can prevent casting to a type that is unrelated to the real type
and later cause a crash because you go into undefined behavior domain
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
add new commands to the contextual menu provided by our files explorer
plugins to allow locking/unlocking a file
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
