This moves the responsibility of asking the user or not for
credentials from the Credentials classes back to the AccountState.
fetch() now only extract credentials from the keychain, reports
the result to the AccountState which then decides if askFromUser()
should be called or not. The result is once more reported to the
AccounState.
This also replaces the HttpCredentials::queryPassword virtual
which now lets HttpCredentialsGui and HttpCredentialsText do it
the way that they prefer.
The AccountState is now the only class responsible for triggering credentials
fetching from the keychain or from the user.
With the ShibbolethRefresher out of the question it's possible
to remove the invalidateAndFetch virtual and manually call invalidateToken.
This also allows us to move that code from Account to AccountState.
In the end this also allows us to move the fetch() call from the
ConnectionValidator and use the same code path as for invalid credentials.
The original problem is that showing a popup not originated
from the main settings window while it's focused won't be
shown in front to the user.
This try not to highjack the user's attention of the user
by showing a notification when checking the connection for
valid credentials, and require the user to sign in through
the UI. There are still issues with showing that popup from
the tray icon, but the user will most likely be looking for
the popup in that case. The new sign in button directly in
the settings account works properly.
Theme will eventually be moved to the GUI
Theme::appNameGUI and QApplicaiton::applicationName are the same, it is currently
set in the constructor of ConfigFile
In particular the 'unsupported client version' error message
is now visible to the user when trying to connect to a
server that no longer supports the current client version.
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
QNetworkReply::OperationCanceledError may be both because of anthentication
error (because the HTTPCredentials abort the reply) or because of a timeout
(the timer abort the reply). We should only ask for the password if the
reply was canceled because the password was wrong.
* Use a shared pointer to Account everywhere to ensure
the instance stays alive long enough for a sync to terminate
* Folder is now tied to an AccountState
* SyncEngine and OwncloudPropagator tie to an Account and use that
for all jobs they run
Issue: Since the setup wizard currently always replaces the
account, it will always wipe all folder definitions, even when
the actual changes to the account were minor.
This allows all the account state information to live in gui
while the sync-relevant data stays in libsync.
I also moved quotainfo to gui since it depends on the account state.
The account state is now managed mostly by the Account itself
instead of through Application. The gui can still control whether
an account is signed out or not.
* Stop the quota job from having an effect on account status
as it can sometimes take a long time to reply. See #2485 and
owncloud/core#12744.
* Instead of indirectly using the quota job, use the connection
validator to regularly ping the server with a basic PROPFIND for
'getlastmodified' on /.
This request was usually fast for users even when the quota PROPFIND
was slow.
