By default QNetworkReply::errorString() often produces messages like
"Error downloading <url> - server replied: <reason>"
but the "downloading" part invariably confuses people since the
error might very well have been produced by a PUT request.
This commit produces clearer error messages for HTTP errors.
Additionally:
* Remove some unnecessary null checks from slots connected to
network job signals and document that these signals never send
null replies.
* There was a bug where AbstractNetworkJob::_timedout wasn't
set when derived classes overrode slotTimeout. We now ensure
it's always set by disallowing overrides of slotTimeout.
Instead it now calls onTimedOut, which allows custom handling.
* Several subclasses declared errorString, isTimedOut. Move
these to AbstractNetworkJob.
* Unify handling of OC-ErrorString (via the new, general
Job::errorString)
* Add documentation in various places.
- I checked every occurence of a '%2' and make correct use of the
QString::arg overload that takes several argument instead of chaining
them, because the first argument can contains a '%1'
- I tried to look for every label that they either use plain text or richtext
and escape the user provided strings in there.
One local folder can now be configured as sync target for multiple
accounts as long as their url and user differ.
Also this patch accepts that the sync folder is behind a symlink.
Also this patch fixes a bug that before the user input was taken
canonically which was not working for the symlink handling.
factorize the function to check the validity of a new folder out of
the folder wizard to the FolderMan.
There is even a test for it now.
That way we can also use it in the normal wizard
If the password or user was wrong during setup, the client showed a
ConnectionClosed error instead of a proper Username or password wrong
message. This was because in HTTPCredentials::slotAuthentication, the
reply is closed, and a property is set to indicate the auth problem.
This patch now checks at all occurences of networkErrors if it might
have been an authentication problem, and displays something useful.
There is a good chance that this is a sufficient fix for
owncloud/enterprise#556
