Ubuntu One Account is not showing in the list of possible accounts.

[Michael Zanetti]

* Start off with a device with no accounts
* Add a Google account
* Go to "add account" once more

=> Ubuntu One is not listed any more

This could be related to bug 1559503 but not sure if it's really a dupe, hence the new report

(Adding an Ubuntu One account through the app store still works, it's just not showing in the list of possible new accounts any more)

phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 24
device name: turbo
channel: ubuntu-touch/rc-proposed/meizu.en
last update: 2016-03-18 09:41:49
version version: 24
version ubuntu: 20160318
version device: 20160304-47be9c9
version custom: 20160314-937-9-57

[Jean-Baptiste Lallement (jibel)]

Actually in my case Ubuntu One is not listed even if there is no google account added.

Tested on
current build number: 286
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en

[Víctor R. Ruiz (vrruiz)]

According to Albergo Mardegan: «With UI designers it was decided not to show an account provider, if there are no installed apps which can use it».

[Selene ToyKeeper (toykeeper)]

I'm seeing this issue too. I went to add a U1 account before installing an app, and couldn't. Arale rc-proposed 284.

[David Barth (dbarth)]

Confirmed. The U1 account should be shown since there is at least the system and app store scope which make use of it.

[David Barth (dbarth)]

The proposed solution (discussed with @mpt in particular) is to add the Ubuntu App Store Scope as the application requiring a U1 account. This will be both informative to the user and ensure U1 appears in the list of account types a user can create from the System Settings > OA panel.

[dobey (dobey)]

The proposed solution is not sensible. The OA panel does not support things that are not applications (as we already witnessed previously when pay-ui was shown there). The item being listed will also present an entirely useless toggle switch being shown to the user, which will have absolutely no bearing on whether the scope can use the account or not.

The correct fix is to make online-accounts not require registered "applications" to be present in order for showing an account in the available providers list.

This same problem also exists with all other account types which may be used by unconfined system services, such as Twitter.

[Alberto Mardegan (mardy)]

On 30/03/2016 23:01, Rodney Dawes wrote:
> The proposed solution is not sensible. The OA panel does not support
> things that are not applications (as we already witnessed previously
> when pay-ui was shown there).

True, indeed the OA panel's main goal is to let users see what
applications or scopes are using an account, and revoke/add permissions.

> The item being listed will also present an
> entirely useless toggle switch being shown to the user, which will have
> absolutely no bearing on whether the scope can use the account or not.

That's not true. Even if the click scope is running unconfined, it can
(and probably should) still check whether its service is enabled or not.
If the service is disabled, the scope should request an U1 account in
the same way that it does when no account is present; OA would them
prompt the user to grant access to the existing UbuntuOne account.
It's not up to us to decide whether this should happen; let's present
our reasons to the UI designers, and they'll decide -- both solutions
are easily implementable.

> The correct fix is to make online-accounts not require registered
> "applications" to be present in order for showing an account in the
> available providers list.

This will not happen, as it pollutes the providers list with lots of
useless accounts. But we can certainly treat UbuntuOne as a special case
and have it always visible. In fact, given the current disagreement on
how to proceed, I'll do this right away so that at least this immediate
issue gets solved.

> This same problem also exists with all other account types which may be
> used by unconfined system services, such as Twitter.

No. While it's true that we have unconfined background services who use
OA to access the accounts, they do that *on behalf of a companion app*,
and in a way that is totally transparent to the user. If the user denies
the Twitter webapp access to the Twitter account, the background service
responsible for checking twitter notifications will see that the
webapp's service has been disabled and won't poll it. And similarly, if
the Twitter webapp gets uninstalled, its .application and .service files
get removed, and the background service will stop polling Twitter.

So, summing up: I will fix this bug by special-casing the U1 account.
The other issue is described in bug 1544033, which -- as the decision
stands at this point -- should be fixed by the click scope by adding a
.application file. If you don't agree with the proposed solution, please
let's continue that discussion on that bug.

[dobey (dobey)]

Should this be closed as a duplicate of that bug then?

And that is not nice about Twitter. I'd say that's a regression. It certainly used to work in the way I described. Requiring an app to say it uses specific accounts for those accounts to appear in the providers list, is, to put it mildly, excessive.

[Alberto Mardegan (mardy)]

On 31/03/2016 18:36, Rodney Dawes wrote:
> Should this be closed as a duplicate of that bug then?

No: this bug is about the U1 account being missing from the providers'
list; the other one is about how the account details page appears for
the U1 account.

> And that is not nice about Twitter. I'd say that's a regression. It
> certainly used to work in the way I described. Requiring an app to say
> it uses specific accounts for those accounts to appear in the providers
> list, is, to put it mildly, excessive.

I don't understand where your complain lies. Let me try to break your
sentence into smaller statements, and pick the right one(s):
1) You don't like the fact that apps have to declare beforehand which
account types they can use;
2) You don't like the fact that accounts which are not used by any app
cannot be created.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[dobey (dobey)]

1) Yes. The way things work on the phone has greatly diverged from the way things work under Unity 7. I thought the goal of convergence was to bring these things closer together, and not to push them further apart. It also doesn't seem to be that they must declare what "types" of accounts they are using, but the specific accounts themselves, and should also be defining their own service information for using those accounts. This also seems to force us into a situation where apps must also provide all their own account providers for all accounts they may theoretically support, rather than simply relying on providers possibly being made available through the installation of other account plug-ins, and if using N apps that support said account, forces the user to necessitate logging in to the same account N times for those N different provider plug-ins.

2) I don't like the definition of "app" we seem to be using here, because it excludes things which are not designed to operate under that definition, and would thus forces us into this "issue."

[Julia Palandri (julia-palandri)]

From what I've seen on my phone (turbo, r44) I'm not even able to add it when I want to update the software: I do get asked all the info (user, passwd, 2fa code) but in the end it doesn't get added and therefore I can't update the software.

[dobey (dobey)]

Setting this to invalid in the scope, and fixed in online-accounts, since mardy's branch has landed, which special cases ubuntuone.