Hi all, Sorry for the late reply. Real life has kept me busy. ;)
@Alberto: Thank you for filing the bug report. :) I don't think that we should revoke the access to account-polld: that's > a setting that's been decided by the user, and if we revoke it then we > should also teach the user how to set it back. It's not trivial, and I > think there are simpler solutions to this. The rationale here was to somehow show the user in a more permanent way that the token has expired. If we don't want to revoke access to account-polld, there needs to be another way of indicating this on the accounts overview page. Furthermore, revoking access would save us from implementing logic in account-polld to stop polling accounts with expired tokens if we cannot recover from the issue. (libsignon-glib can indicate what exactly was the reason, so we could find some, e.g. "invalid credentials", that we mark as non-recoverable.) I want to argue that this logic be placed elsewhere. If/when account-polld > becomes unnecessary, we lose this logic. So any code we add to > account-polld that we want for all time, essentially becomes technical debt. > > And if a Google account is broken, who is going to tell the user if > account-polld does not “see” it? If account-polld is the canary in the > accounts mine, then a broken Google account only accessed by calendard and > contacts, will stay silently broken. > +1 The account is not broken :-) Can't we consider it to be broken if libsignon-glib yields an "invalid credentials" error? The fact that account-polld encounters this error means that any other > app *using the same application key* as account-polld will meet the same > error. I would argue that no other app should use the same key, so the > problem lies almost entirely on the app which encounters the error. I would argue that this does not hold if we are talking about the afore-mentioned "invalid credentials" error. ;) In order to solve the authentication issue with account-polld we need to > find a UI process which can repeat the authentication with the same > account, using the application key from account-polld. This could be > Dekko, or indeed it could be some component in Online Accounts itself. Personally, I wouldn't want to put this code into Dekko. What if the user never opens Dekko or even uninstalls it? I believe that we could have something similar on the phone, but since > the amount of work (and risk) is quite considerable, I'd rather wait to > see the UX designers' plan on how this should work UX-wise, and then > come up with a technical solution which implements that. Sounds sane. :) Cheers, Niklas 2015-10-19 13:20 GMT+02:00 Alberto Mardegan <[email protected]> : > On 19.10.2015 12:53, Andrea Bernabei wrote: > > Is there a bug already to track that? Does UX know that you're waiting > > for such a solution? > > If either of the answer is false, we have to fix that first :) > > I was relying on IRC, but your suggestion is indeed most reasonable: > > https://bugs.launchpad.net/ubuntu-ux/+bug/1507540 > > Ciao, > Alberto > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
