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.
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.
* The sharing ui does a propfind anyway: use that to query the new
property as well!
* For the socket api, asynchronously query the server for the right url
when an action that needs it is triggered.
The old, manually generated URL will be used as fallback in case the
server doesn't support the new property or the property can't be
retrieved for some reason.
Depends on owncloud/core#29021
* SocketAPI has COPL_LOCAL_LINK / EMAIL_LOCAL_LINK commands
* The nautilus and dolphing shell integrations show a submenu from which
one can share as well as access the private link.
* The SocketAPI provides a new GET_STRINGS command to access localized
strings.
* The private link can also be accessed from the user/group sharing
dialog.
* The numeric file id is extracted from the full id to create the
private link url.
Use qCInfo for anything that has general value for support and
development. Use qCWarning for any recoverable error and qCCritical
for anything that could result in data loss or would identify a serious
issue with the code.
Issue #5647
This gives more insight about the logs and allow setting fine-tuned
logging rules. The categories are set to only output Info by default
so this allows us to provide more concise logging while keeping the
ability to extract more information for a specific category when
developping or debugging customer issues.
Issue #5647
Starting from oC 10.0.0 having several public link shares with
different attributes for a path will be supported. This adds
functionality to create, edit and delete these public link shares.
The behavior is currently gated by server version, but should be
adapted to use a capability as soon as one is introduced, see
owncloud/core#27622.
The UI reduces to a single-share version when talking to older servers.
Testing scenarios:
* Link sharing is disabled (by capability, not by theme)
* Required passwords
* Required expiry
* Forbidden 'allow upload' for folders
* New and old servers
Now we have 1 simple dialog that includes 2 widgets.
* ShareLinkWidget (for link shares)
* ShareUserGroupWidget (for user/group shares)
The ShareUserGroupWidget is only included if the server version is >=
8.2.0
For <8.2.0 the old behavior is preserved
There is now a generic OCSJob which must be inherited by other jobs. This is in
prepartion for the other OCS job that will come (for the Sharee API endpoint
for example).
More logic is moved from the sharedialog to the OcsShareJob. So in the GUI code
we now only say what we want (a new share, set the password etc). And the code
in libsync will make that happen. Error handling is for now still done in the
GUI part.
For now the ocsjob and ocssharejob live in gui but probabaly we should
create a libshare or libocs at some point.
