When an app wants to use an account, it first needs to be authorized by the user. This is an offline operation, which happens locally on the user's device. It's handled by dialogs in the second column of
https://wiki.ubuntu.com/OnlineAccounts?action=AttachFile&do=get&target =online-accounts-flow-extended.png (note that the dialog at the bottom, is the dialog that handles the account creation, essentially the same that the user would see if he created the account from System Settings -> Online Accounts: the only difference is that once the account creation completes successfully, the application is added to the whitelist of apps which can use the account -- again, it's just a local operation) As soon as the application is granted the permission to use an account, typically it will try to get its password or authentication token; when dealing with OAuth, most of the times the very first time that this happens the remote server will run its own checks and require us to show a webview to the user, asking an additional confirmation (after which, the server remembers that this app has been authorized to use the account, and will return us an access token, which is specific to that app. Now, access tokens do expire. It can be a matter of hours, but most typically it's months or even years. When that happens, we need to show the remote server's contents in a webview and the user will have to renew the authorization. The dialogs you added on the right column cover exactly this case: it's when an app which is *already locally authorised* to use an account finds out that the access token is no longer valid (or password, if the user has changed it on the remote server -- think of UbuntuOne, which is not OAuth based). I think that your design covers the needed cases, but I belive that the "Allow" and "Do not allow" buttons you have on the third column are misnamed: I would rename "Allow" to something like "Renew authentication". As for the "do not allow", I would either remove it completely or (better) rename it do "revoke authorization": it's effectly about *locally* toggle the "enabled" flag for the requesting application, so that it will stop ever trying using this account (and if the user opens the account in the System Settings, he'll see that the app is now disabled). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to unity-control-center in Ubuntu. https://bugs.launchpad.net/bugs/1522360 Title: Online Accounts authorization on desktop (unity7) is confusing Status in unity-control-center package in Ubuntu: Triaged Bug description: Unlike the phone (unity8) interface, in the desktop (unity7) when a Google account is created in "System Settings" -> "Online Accounts", all applications which can use it get automatically enabled. Some of these applications, such as Shotwell, have their own UI and use the account only when the user is actively using them, while others (such as Empathy and Evolution) provide background services which start synchronizing the user calendar or contacts as soon as the account is created, but without showing any UI on screen. Now, the problem is that the first time that these processes start using the newly created account, they need to be authorized by the user: this is not something that we can control, as it's a requirement from the remote server (Google's, in this example). This means that until we show a UI containing the Google's authorization page, these application won't work. The solution we implemented (and that we are currently using) is that when these applications try to authenticate, we refuse their request and instead emit an OSD notification, saying Applications can no longer access your Google Online Account Choose <b>Online Accounts</b> from the user menu to reinstate access to this account. If the user is clever enough, he'll open "System Settings" -> "Online Accounts" and after clicking on the Google account they'll be prompted to authorize the applications that previously requested access to it. Until the user has done that, these applications won't be able to interact with the account. Some users (actually, Canonical developers) have been left confused by this message, thinking that it was the symptom of an error that had to be fixed. I would like to propose a couple of simple suggestions to fix this bug: 1) Reword the notification message a bit, maybe by saying "Some applications cannot access..." (note that I removed "no longer") 2) Some releases ago, the system settings indicator on the top right corner of the screen would become red in this situation, and also the "Online Accounts" menu item inside that menu would appear in red: that helped a lot our users in finding their way. However, this no longer happens. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1522360/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
