Need more information from account manager

Bug #1638769 reported by Michi Henning
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
webapps-sprint
Fix Released
High
Alberto Mardegan
online-accounts-api (Ubuntu)
Fix Released
Undecided
Alberto Mardegan

Bug Description

For storage framework, we need to be able to present the user with a selection dialog that allows the user to select a cloud service account, for example, to select where backups should be stored, or where the camera app should upload photos to.

Right now, we only get three values from online accounts:

id (integer)
service id (e.g. “google-drive-scope”)
display name (e.g. “<email address hidden>”)

This isn’t quite sufficient for what applications need. In particular, they need a (translated) display string that identifies the service (e.g. “Google”, “Dropbox”), and they need the icon identifier.

Without these things, it’s not possible to present a decent selection dialog, and it’s not possible to reliably distinguish accounts, such as when a user has more than one account with the same service, or has accounts with different services but the same email address.

Could you please add the following to the account information dictionary:

- provider ID
- translated provider name
- icon name

Related branches

Alberto Mardegan (mardy)
Changed in online-accounts-api (Ubuntu):
status: New → Confirmed
assignee: nobody → Alberto Mardegan (mardy)
Revision history for this message
Alberto Mardegan (mardy) wrote :

I agree that this information is needed by the clients.

The question is about the icon: the client might be unable (due to apparmor confinement) to read the provider icon, especially if this is coming from another click or snap package. If, as I understand it - please confirm this - the storage framework will be running inside the unity8 snap, then this is not a problem for your specific use-case, but it's an issue that anyway we need to consider for third party clients.
I guess that for the time being the simplest solution is to simply have an "iconName" field with the icon name as a string, and later on we'll think of a solution for the general case (I hope we can find something better than passing the icon data over D-Bus!).

Revision history for this message
Michi Henning (michihenning) wrote :

Thanks Mardy!

Passing icon data over DBus would be sub-optimal, yes. For clicks, I don't think we'd have a problem with the app resolving the icon name. (I assume that the default apparmor profile for apps will allow this.) I don't know what the story will be for snaps. Presumably, there will be some interface that apps are allowed to use to retrieve icons?

Alberto Mardegan (mardy)
Changed in webapps-sprint:
status: New → In Progress
assignee: nobody → Alberto Mardegan (mardy)
importance: Undecided → High
milestone: none → sprint-27
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package online-accounts-api - 0.1+17.04.20161110-0ubuntu1

---------------
online-accounts-api (0.1+17.04.20161110-0ubuntu1) zesty; urgency=medium

  * Add provider information to public API (LP: #1627001, #1638769)

 -- Alberto Mardegan <email address hidden> Thu, 10 Nov 2016 09:13:34 +0000

Changed in online-accounts-api (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
James Henstridge (jamesh) wrote :

Is this actually working as intended?

Looking at the changes in the latest package it only affects the GetAccounts() call, so we don't get back the additional account metadata from the RequestAccess() method, or the AccountChanged signal.

Further more, the extra "services" return value from GetAccounts() seems to be empty here:

    $ gdbus call --session --dest com.ubuntu.OnlineAccounts.Manager --object-path /com/ubuntu/OnlineAccounts/Manager --method com.ubuntu.OnlineAccounts.Manager.GetAccounts {}
    ([(uint32 8, {'authMethod': <3>, 'displayName': <'james@localhost:8888/owncloud'>, 'serviceId': <'storage-provider-owncloud'>, 'settings/host': <'http://localhost:8888/owncloud'>}), ...], @aa{sv} [])

Was there any reason not to just ship this extra account information as part of the existing a{sv} dict used by all the existing methods?

Revision history for this message
Alberto Mardegan (mardy) wrote :

At the moment, we don't properly handle the case when new providers are installed on the system: the client will continue seeing the old provider's list. You can file a bug for that, but I don't think this is a critical issue.

The client retrieve the provider list (along with the existing accounts list) when the Manager gets initialized, and we assume that this list doesn't change. The RequestAccess() method and the AccountChanged signal only carry the serviceId field, which can then be used to look up the provider information in the provider list (which also contains the serviceId). Give that the you might have several accounts for the same provider, we are not replicating the provider information for each account.
However, this should not be a concern of the client, since the client library already tooks care of resolving the mapping (if it doesn't, please file a bug).

To quickly test the new API, you can get the Account Tester app from https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings-online-accounts (version 0.15, it's the one linked in the "provider-data" test case).

for testing with gdbus, remember that you need to pass the applicationId as parameter to the GetAccounts call (you can omit it, if you are a confined app).

Revision history for this message
James Henstridge (jamesh) wrote :

I tried downloading your accounts-tester repo, and ran "qmlscene provider-tester/app.qml". It shows an empty window with a "create a new account" button at the bottom. When I click that, it shows an empty "Choose provider" page. On the console, it printed the following:

    virtual void OnlineAccountsModule::Plugin::registerTypes(const char*) Ubuntu.OnlineAccounts
    OnlineAccounts: GetAccounts call failed: QDBusError("com.ubuntu.OnlineAccounts.Error.PermissionDenied", "App 'it.mardy.account-tester_provider-tester' cannot act as 'it.mardy.account-tester_provider-tester'")

This is on an up to date Zesty install.

But again: is the output I'm getting from the above "gdbus call" invocation expected? I'm getting a set of accounts returned but no provider name or icon information.

Alberto Mardegan (mardy)
Changed in webapps-sprint:
status: In Progress → Fix Released
Revision history for this message
Alberto Mardegan (mardy) wrote :

I'll investigate why are you are getting that error with the tester app; it works fine on the phone.

Anyway, yes, the output you are getting from gdbus is expected, because you are not specifying the applicationId in your call to GetAccounts. You need to ship an .application file along with your app, and install it in /usr/share/accounts/applications/. See existing files there as examples. And have a quick look at https://developer.ubuntu.com/api/apps/qml/sdk-15.04/Ubuntu.OnlineAccounts.manifest-files/

Given that your project is rather generic and might not have prior knowledge on all the available account types it support, it might be a good idea for you to define a <service-type> (you could call it "ubuntu-storage-framework", for example) instead of listing all the individual services you support. But it's really up to you.

Revision history for this message
Alberto Mardegan (mardy) wrote :

I checked the error with the Account Tester app: the error message is misleading, the reason for the failure is that probably you didn't install the click, so the click hook that should create the .application file didn't run, and therefore the service doesn't know who this app is.

Revision history for this message
Michi Henning (michihenning) wrote :

Hmmm... This is not working for me. I have a Google Drive account configured. When I call GetAccounts(), the account is returned. But the account information I get doesn't include what we need.

We need the translated provider name (e.g. "Google Drive"), the icon name, and the DBus name (e.g. "com.canonical.StorageFramework.Provider.McloudProvider").

I can't get at this information through the methods provided by Account. I had a look at the returned dictionary, but it only contains authentication information.

How can I get at the three extra bits of info we need?

Revision history for this message
Michi Henning (michihenning) wrote :

I've opened a separate bug here, seeing this one is closed:

Bug #1643732

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.