desktop-packages team mailing list archive

[Alberto Mardegan <1522360@xxxxxxxxxxxxxxxxxx>]

On 04.01.2016 20:59, Matthew Paul Thomas wrote:
> "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"
> 
> Is this true on the phone as well? If not, how does the phone avoid
> this? And if so, the phone Online Accounts design needs changing too.

It is true on the phone as well: Once the user clicks on our "Allow"
button on the phone, we only authorize the application to use the Online
Account data which we have locally, but then when the application
actually uses this account's data on the remote server, the remote
server might want to send the user through a web-based authorization.
Usually this happens on the very first time the user wants to use this
application on his account: that is, if the account gets deleted locally
and then the user performs the same steps again, he generally won't be
asked to reauthorize the app, because the authorization is remembered by
the remote server (though, that's totally up to the remote server:
Google and Facebook generally remember the apps, but other services don't).

When this happens on the phone, most of the times these authorization
requests are initiated when the requesting app is running on the
foreground, so we simply show the "trusted session" UI on top of the
app, containing the webview with the remote service's autorization page.
This is usually not a disruption of the user's activity because it
typically happens after the user has explicitly asked the application to
perform some action.

I'd say that the problem only involves those system services which run
on the background; these are much more common on the desktop than on the
phone, but indeed the issue is not limited to the desktop only. See for
example bug 1507540.

[...]
> In this case we can't Just Do It. So, we should provide a button to do
> it. What should that button look like? We're allowing the service to
> access a particular account, so let's label the button "Allow". To make
> the alternative obvious, we should have another button for that, "Don't
> Allow". And of course we should identify the service and the account it
> wants to access, so let's use text for that, above the two buttons.
> 
> By now this should be sounding very familiar ... It's the standard
> Online Accounts dialog! The only difference here is that we have to show
> the Web UI afterwards, so "Allow" should be "Allow…". That's all.
> 
> Now, I guess you're going to tell me that reimplementing that in Unity 7
> would be far too invasive. If so, let me know how much you're
> comfortable implementing, and we'll see how close we can get.

As I explained above, the problem is different: this is about notifying
the user that an application *other than the active one* (so, it could
be a system service or an unfocused app) needs his attention. I don't
think we want to popup a dialog in that case.

-- 
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:
  In Progress

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