Merge lp://qastaging/~renatofilho/ubuntu-system-settings-online-accounts/update-account-removal-message into lp://qastaging/ubuntu-system-settings-online-accounts

FAILED: Continuous integration, rev:285
http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-ci/220/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-wily-touch/400/console
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-wily-amd64-ci/8
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-wily-i386-ci/8
    FAILURE: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/292/console
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/400
        deb: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/400/artifact/work/output/*zip*/output.zip
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/21994

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-online-accounts-ci/220/rebuild

Thanks Renato. But the UI specs still show the old text here:

https://wiki.ubuntu.com/OnlineAccounts#Phone

Are you suggesting these changes yourself, or have they been approved by design?

Online Accounts can't know what an app is doing with a particular account type. It doesn't know, for example, whether my app is using a Google Account for publishing YouTube videos, tracking stocks in Google Finance, or accessing Google Docs for offline reading. And it doesn't know whether, and if so how, my app is caching that data. So it can't possibly delete "all associated data" when I remove the account, and this message would be incorrect.

I understand that you have special-cased syncing of particular data types for particular account types, namely calendars, contacts, and e-mail. You could delete the system-wide copies of *that* data. But you still would not know whether individual apps had cached that data or not, or whether they were using the same account for anything else.

When iOS says that removing a Google account "will remove its calendars, notes and contacts", it can be confident about calendars and contacts because it provides apps with access to those particular things -- via EventKit and ABAddressBook* respectively -- and not to the Google account itself. (I don't know understand what "notes" refers to in the message, though.)

@mpt
What do you propose we do then?

I suggest leaving the text as it is. You can't say any more because you don't know any more.

@mpt

Could we use something similar as android does: "Removing this account will delete all of its messages, contacts, and other data from the phone!" Since we know that all "contacts and messaging and calendar events" will removed for sure.

As I said, you could delete the system-wide copies of that data, but you would not know whether individual apps had cached that data or not.

You know that third-party apps aren't accessing those system-wide copies, as long as it's impossible for them to do so -- bug 1227821, bug 1227824, and the equivalent for messages.

But third-party apps have direct access to the Google account. So regardless of whether those bugs are fixed -- and more likely, as long as they aren't fixed! -- third-party apps can use https://www.googleapis.com/calendar/*, https://www.google.com/m8/feeds/contacts/*, etc directly and save copies of the data themselves. You don't know whether they have or not. So you can't say that "Removing this account will delete all of its messages, contacts, and other data from the phone". You just don't know that.

The third-party apps should not store the contacts,calendar,messages on application local database. They should use The contact, organizer, telepathy/messaging, sync service implement plugins.

With that we can make sure that if the account is deleted all data is deleted together.

PASSED: Continuous integration, rev:286
http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-ci/221/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-wily-touch/427
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-wily-amd64-ci/9
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-wily-i386-ci/9
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/313
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/427
        deb: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/427/artifact/work/output/*zip*/output.zip
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/22071

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-online-accounts-ci/221/rebuild

I would like to understand a bit better what happens when the user removes a google account. My previous understanding is that synchronization of contacts would stop working, but the contacts that were imported from the google account would remain. Is it correct, or are they removed as well?
And if the latter, would the contact reappear automatically, if/when the account is re-added again?

Then, about messages: what messages are we talking about? Are we planning to integrate with Google XMPP chat?

And last: ordinary (confined) applications cannot distinguish whether an account has been removed or just disabled: they just see it disappear. It looks like you want to treat these two events differently -- I guess you may, since your processes run unconfined. However, I think this would be inconsistent with how the rest of the applications work, and ultimately cause more confusion to the user.

I would propose a different approach: when an account is deleted or disabled, just stop synchronising contacts and messages, but keep them there. Then, next time the user opens the Contacts or Messages application (or maybe when the user performs a certain action inside these applications, for example clicking the "sync" icon or opening a conversation with an account which no longer exists), popup a dialog with something like:

   You have removed Contacts access to the account <email address hidden>:
   do you still want to keep old contacts associated with it?

           Keep Remove contacts

And a similar thing for the Messaging app.

One more option is to have a configuration panel inside the messaging app, where you can decide to remove conversations older than XX days. So you wouldn't need to ask anything to the user, and the conversations associated to a deleted account would automatically be deleted after some time, without the user intervention.

> I would like to understand a bit better what happens when the user removes a
> google account. My previous understanding is that synchronization of contacts
> would stop working, but the contacts that were imported from the google
> account would remain. Is it correct, or are they removed as well?
> And if the latter, would the contact reappear automatically, if/when the
> account is re-added again?

The contacts and any data synced from this account will be removed.

>
> Then, about messages: what messages are we talking about? Are we planning to
> integrate with Google XMPP chat?

We are implementing a new framework called "messaging-framework" this framework will run as a telepathy plugin but with Canonical API (we will have some kind o glue code to integrate it with telepathy). Since telepathy is integrated with our history service, all messages will be stored on a system-wide log file. The messages related with this account will be removed as well.

>
> And last: ordinary (confined) applications cannot distinguish whether an
> account has been removed or just disabled: they just see it disappear. It
> looks like you want to treat these two events differently -- I guess you may,
> since your processes run unconfined. However, I think this would be
> inconsistent with how the rest of the applications work, and ultimately cause
> more confusion to the user.
Yes we do not have control over third party applications. We can not guarantee that the data will be removed. We can not say in the message that all data will be removed.

>
>
> I would propose a different approach: when an account is deleted or disabled,
> just stop synchronising contacts and messages, but keep them there. Then, next
> time the user opens the Contacts or Messages application (or maybe when the
> user performs a certain action inside these applications, for example clicking
> the "sync" icon or opening a conversation with an account which no longer
> exists), popup a dialog with something like:
>
> You have removed Contacts access to the account <email address hidden>:
> do you still want to keep old contacts associated with it?
>
> Keep Remove contacts
>
> And a similar thing for the Messaging app.

Address book app is not a sync app it only contains the sync button because we did not find a way to automatically sync the contacts if the contacts get changed on the service side (the idea is to implement something with push-notification, and remove the button from address-book-app).
The address-book-app just handle data already synced in the device it should not care about accounts and synchronization.

We have already discussed that with designers, Keeping the contacts/messages/calendar will cause more problems than benefit. If we allow the user to keep the contacts, we will need a interface to give the option to remove it in the future (remove all contacts from a specific account, not removing individual contacts). Another big problem is the case where the user decided to re-add the account, all contacts will be duplicated because the old contacts was liked to the other account, and some others small problems.

All systems (android, IOS...

> The third-party apps should not store the contacts,calendar,messages on
> application local database. They should use The contact, organizer,
> telepathy/messaging, sync service implement plugins.

Right now they can't, because of bug 1227821 and bug 1227824 (unless those bug reports are inaccurate, in which case we have a security problem).

By the time those functions are provided, depending on how many apps exist, it would take time for them to migrate to the "right" way of doing things.

And even if they do migrate, you don't know whether they have or not. A brand-new app in 2018 could still do things the old way, copying data directly from Google, because Online Accounts still gives it direct access to the Google Account.

> With that we can make sure that if the account is deleted all data is deleted
> together.

As long as you are only saying "should not", rather than "can't possibly", you aren't making sure.

PASSED: Continuous integration, rev:287
http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-ci/222/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-wily-touch/460
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-wily-amd64-ci/10
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-wily-i386-ci/10
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/334
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/460
        deb: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/460/artifact/work/output/*zip*/output.zip
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/22179

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-online-accounts-ci/222/rebuild