You'd expect that after a conflict resolution the file watcher would
pick up the change and trigger a sync. For some reason it doesn't seem
to happen on at least some Ubuntu systems. In such cases the user would
then still have a stale conflict entry in the activity list and wouldn't
be able to do anything with it.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This should be safe in the case of conflicts in folders on which the
user can write. For other cases we still use the older actions.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The socket api move and delete commands are not strictly about conflicts
since they also deal with files which couldn't be uploaded for some
other reason. Still the new ConflictSolver could be used in those cases.
This opens the door at reusing that logic in other places.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This could only work at the root of the sync folder where the record for
the parent folder would be invalid. Otherwise the negation would be
wrong... assuming you can add a file only if the permission is not
there.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
For conflicts generally as well as new files in read-only directories
the context menu will now present delete and move options.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
I wrongly (and stupidly) assumed the int in QBitArray was treated as a
hash as well but it is an index so it must be positive. Also to make
things even worse I misread on which expression clang-tidy was
complaining regarding the implementation specific narrowing
conversion... This is happening after the modulo operator and not
before. We're in a safe range of values at that point, so it's fine to
let the narrowing happen.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This flagged mostly unused parameters. Didn't enable the
misc-non-private-member-variables-in-classes check as we got a lot of
those. Hopefully we'll get to fix them at some point but that feels too
early and too much work for now.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Those files and folders are not shareable and the "Edit" or "Open in
browser" actions will lead to showing an error in the web GUI. No need
to lead users there so just disable them.
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>
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>
- Allow direct editing "Edit" when an editor is available for the mime type
- Show "Open in browser" if editing is unavailable (as previously)
(now on top of the menu list)
- Rename the menu title to the app name, "Nextcloud" instead of "Share via ..."
Signed-off-by: Michael Schuster <michael@schuster.ms>
Fixes#1485
This was missed when creating the new share dialog.
Now it pops up with a nice share password dialog to enter for your link
share.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* The new menu option will fetch shares and create a new link share if
no "context menu share" currently exists.
* Various cleanup of common operations in socketapi happened as well,
in particular there's now FileData::get() that calculates all the
relevant paths that are useful for most socketapi actions.
This adds "Open in browser" entry in the menu (Issue #5903)
Also mark the entries as disabled when the file is not yet on the server.
If re-sharing is not allowed for that file, a disabled explaination
entry is added to the menu.
If sharing is disabled globaly in the branding or in the server,
the share entry will not be present.
(Issues #4205 and #4608)
Meta issue #6292
To do this conveniently a bunch of functionality that's common to
IssueWidget and ProtocolWidget is moved to ProtocolItem.
Also the convenience function to asynchronously retrieve the private
link url is moved from the socket api to the network jobs.
Some servers have non-compliant instance ids (that start with a number)
and thereby make deducing the numeric file id from the full id
unreliable.
To circumvent this problem we retrieve the fileid property from the
server with a PROPFIND.
The current implementation would return the same value whether the query failed
or if no row would be found. This is something that is currently checked by csync
and needs to be provided if we want to use SyncJournalDB there.
Adjusted all call sites to also check the return value even though they
could still just rely on rec.isValid(), but makes it more explicit as to what
happens for database errors in those cases, if we ever want to gracefully handle
them.
This is motivated by the fact that QMetaObject::noralizeSignature takes 7.35%
CPU of the LargeSyncBench. (Mostly from ABstractNetworkJob::setupConnections and
PropagateUploadFileV1::startNextChunk). It could be fixed by using normalized
signature in the connection statement, but i tought it was a good oportunity
to modernize the code.
This commit only contains calls that were automatically converted with clazy.
