Add a test to test the data fingerprint feature make me realize it was broken.
The code was relying in the distinction between empty and null QByteArray,
but this was a bad idea as this difference is lost when going through QString.
The server reply with a code 400 when the token is invalid,
the client was understanding this error as a network error, and was retying
again with the same token.
Instead, we must rely on what the json is saying, even if the reply is
not a 200 code.
Issue https://github.com/owncloud/enterprise/issues/2777
The check was added for #6317 in commit
13eb64584f.
We did see missing mtimes in replies in tests with live servers though.
Possibly those were old incomplete responses cached in the stat cache?
- Adds issue_template.md to folder .github - previously bug_report.md.
- This will enable the issue template when users creates issues.
Signed-off-by: Camila San <hello@camila.codes>
Note that we also needed to adjust the server url to contains the user name
in the folder wizard. (As checkPathValidityForNewFolder expect the user name)
Issue #6654
The exact string is actually "sync.*.debug=true\ngui.*.debug=true".
And this is not strictly equivalent to setting the env var, as it
calls QLoggingCategory::setFilterRules.
Over all, that's an implementation details that users do not care about.
Not having these enabled by default is causing significant extra back
and forth with reporters since they must manually use --logdebug for the
log to be useful.
Fix a strange warning seen on the log from the CI on Windows in
https://github.com/owncloud/client/pull/6621
The test shows, at the beginning
QObject::connect: No such signal DesktopServiceHook::destroyed(QObject*)
And crashes at the and.
My guess is that when QDesktopServices::setUrlHandler is called, the
QMetaObject is not yet initialized
But this is probably not the reason of the crash
There is no real reason to have a timeout. The connection can stay open
as long as we are not authenticated. The User can still re-open a browser
from the UI at any time.
Issue #6612
* Disentangle the previous 'qdbusWorkarounds' into three different
things
* Make not trusting tray.isVisible() a new workaround
* Introduce env vars for all workaround flags
* Use the workaround flags for OSX
* Determine workaround flags for KDE when the plasma integration plugin
is missing
This can happen when the client is started and the internet connection
was not enabled. Then we would fetch the credentials, but we would
no do the refresh token step (because network is down).
So next time we try to connect, we would also not refresh the token
because the credentials are not marked as 'ready'
Reported in
https://github.com/owncloud/client/issues/6522#issuecomment-396845167
It could happen that readyRead was emitted for incoming data while the
download was not yet finished. Then the network job could finish with
no more data arriving - so readyRead wasn't emitted again.
To fix this, the finished signal also gets connected to the readyRead
slot.
