Can't disable online account when "grant access" is being requested

[Joseph Wakeling]

The off/on toggle for an online account is not visible when the account requests the user to "grant access".

This creates problems when there is an account that is consistently failing to log in, as is currently the case with the Facebook account -- see: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+bug/1180297

It's strongly desirable to be able to disable the account in this case, as a side-effect of the login failure is that the web browser keeps opening again and again with the attempted login URL -- but the online accounts settings do not allow for this as the "grant access" request appears in place of the on/off toggle.

[Alberto Mardegan (mardy)]

Good point! Adding the design team in the loop.

[Joseph Wakeling (webdrake)]

Thanks Alberto!

Would be really great to have a workaround here -- I wasn't able to work out how to edit config files manually to disable the account. (Actually, I simply couldn't find where the setting was stored.)

[Alberto Mardegan (mardy)]

Joseph, as a temporary workaround you can use the account-console command from the account-plugin-tools package. You can run:

    account-console list
    account-console edit --disable 123

where "123" is the id of the Facebook account, as reported by the "list" command.

[Joseph Wakeling (webdrake)]

Belated thanks for the workaround. Works nicely. :-)

[Katie Taylor (katie-t)]

When an account requires the user to 'grant access', the two actions available at that moment are: grant access; remove account.
An account which is asking the user to 'grant access' the account is not at that moment active. I think it's unnecessary to be able to disable an account which is not fully functioning.

[Joseph Wakeling (webdrake)]

Katie, I think you have misunderstood the problem from a usability point of view. The point is that in the case of an online account login error that is not the user's fault -- e.g. the cited Facebook problem -- Ubuntu will keep trying to log the user in and/or request new access details. This in turn may have very intrusive side-effects for the user (e.g. in the case of the Facebook problem, a new browser tab would be opened every few minutes).

In such circumstances it's essential to explicitly disable, and not remove the account -- in order to prevent the account from continually trying to log in. But there is no way to do this from the GUI, only the command-line procedure outlined by Alberto.

[Katie Taylor (katie-t)]

I don't think there is a need to disable rather than remove the account.
In this situation, most users would want to remove the account to prevent further errors.
The account can always be added again in the future.

[Joseph Wakeling (webdrake)]

I can only say that this was an issue that affected me, and that I wanted to disable rather than remove, because I wanted to ensure that the account (in this case, Facebook) could be re-enabled the moment the login bug was fixed. I also didn't want to risk deleting account history such as chat logs.

[Joseph Wakeling (webdrake)]

Just to give you an impression of my own experience, here's what happened:

* I had a perfectly working Facebook account activated via Online Accounts, which I used for months.

* Out of the blue: "Ack! Empathy won't log in to my Facebook account, but Firefox keeps opening new tabs or browser windows with some kind of Facebook link. Has my computer been hacked?"

* ... following some Googling to track down the source of the problem: "OK, so Online Accounts will keep failing to log into Facebook because of this change Facebook has made to their login system. So, now I just need to stop Online Accounts from keeping trying to log in to Facebook, so I don't get these browser tabs keeping on opening every 10 minutes."

* "I don't want to remove the account because I have chat history and so on stored there, I just want to disable it ..."

* "... oh. I can't disable it from the GUI because the 'Grant Access' button appears in the place where the 'Disable' button would have been."

[Katie Taylor (katie-t)]

That sounds really frustrating. Thanks for providing more detail - I understand not wanting to delete any associated history.
In the current design the per-service enable/disable buttons should still be visible, and can be used in the absence of the global disabling button.
Alternatively (and with the tab-opening bug fixed) one can leave the account in a state of 'requesting-access' (i.e. do nothing) - no data will be lost.

[Joseph Wakeling (webdrake)]

Thanks for sticking with me on this one :-)

I'm not sure what you mean by per-service enable/disable buttons. I've attached a screenshot that shows what I can see when I attempt to edit the Facebook account in online accounts -- there is no enable/disable button or switch that I can see, only the "Grant Access" button that appears in place of the on/off switch (this is in 13.04). Or are you referring to an updated design in the 13.10 alphas?

[Katie Taylor (katie-t)]

The per-service buttons are the ones next to Photo search plugin, Empathy and Shotwell in your screenshot. :)

[Joseph Wakeling (webdrake)]

.... D'oh! :-P

Well, that was an interesting usability lesson. It just never occurred to me to flip those switches in the UI -- I've never used them for any purpose, ever.

Now for the bad news -- disabling all the services for the Facebook account does not prevent the attempts at Facebook login, with the browser tabs opening as a consequence. (Much to my disappointment -- having made those tweaks, I thought it _had_ fixed things, and was just about to post a comment to that effect when suddenly, up popped a new tab with the login-related Facebook URL.) It does seem to make the login attempts less frequent, though.

Screenshot attached of updated Online Accounts settings, just to be sure everything is correct.

[John Lea (johnlea)]

@webdrake; Hi, I just noticed you changed the status of this bug in the ubuntu-ux Launchpad project. Thank you very much for the time you have invested in looking into this issue, but please refrain from changing the bugs status in the "ubuntu-ux" Launchpad project.

The status of bugs assigned to this project should only be changed my members of the ubuntu design team, if you would like the status in ubuntu-ux changed please contact the relevant designer (in this case Katie). For triarged bugs, the relevant designer from the ubuntu design team can be identified by seeing who the bug is assigned to in the ubuntu-ux project.

Reverting to 'invalid' now, but Katie can then re-change the status.

[Joseph Wakeling (webdrake)]

@John, thanks for the correction, and apologies for any hassle caused. I'd like to add a note of particular thanks to Katie for the time and attention she's given to understanding the issue -- it's very much appreciated, regardless of whatever decision is made on how to proceed with this issue.

[Alberto Mardegan (mardy)]

Hi Joseph, in regard to what you wrote in comment #13: disabling the individual services should indeed stop all the activity on the facebook account; if it doesn't, it's a bug in some of the applications using the account.
Unfortunately, it's not very easy to find out which one it is, but it must be either empathy or the photo lens. Does the authorization request happen after you search something in the Dash (after several seconds from that, probably)? Do you have your chat status set to "Available"? If you open Empathy, does it say that the facebook account needs authentication?

Also, try does the authentication requests occur after you log out and in again?

BTW, the facebook bug is bug 1180297, and it has been fixed; please read comment #34 there. :-)

[Joseph Wakeling (webdrake)]

Hi Alberto -- thanks for the heads-up. For now, I'm still getting the same problems for now if I re-enable the Facebook account. If I understand correctly the statuses listed in #1180297 the fix has not actually been released in Quantal or Raring yet ... ?

I'll have a play with the per-service settings and see if I can identify what application might be at fault.

[Joseph Wakeling (webdrake)]

> I'll have a play with the per-service settings and see if I can identify what application might be at fault.

Apologies, the Facebook fix landed before I could do this. :-(