GNOME Bugzilla – Bug 660378
Restore of 3.1 backup in 3.2 breaks Google accounts
Last modified: 2012-05-17 12:01:15 UTC
My steps to reproduce: a) Backup a running configuration with multiple Google accounts setup in Online Accounts. In my case, I had - Three accounts configured, two for just calendar service, the other for all services except calendar - For the Online Account with the disabled the calendar I had re-configured it directly (not through Online Accounts) in evolution (to test some other bugs). b) Upgrade to 3.2 (Ubuntu 11.10 Beta 2 Packages) c) Clean up evolution data (purge .local, .config, .cache, .camel_certs, .gconf) after process cleanup (no evolution processes running). Remove Online Accounts that are configured. d) Reboot (for clean gconf) e) Start evolution client which launches the setup/restore wizard and select the 3.1 backup f) Evolution loads and displays the following error message Error while performing operation. Cannot find a corresponding account in the org.gnome.OnlineAccounts service from which to obtain an authentication token. All my Google calendar and contacts are missing except for the one Google calendar that was configured directly in evolution.
Note that the backup tool is broken at the moment (bug #659742).
On the other hand, each account/source added through Online Accounts interface is fully managed by that interface, thus if you remove it from the Online Accounts, then they are supposed to be removed from evolution too - also because they are authenticated with a token provided by Online Accounts interface. Thus it seems to me that the bug is that all accounts were not removed as expected. Will this work better with a fix from bug #660721?
In the case where the user is restoring to a fresh install, the Online Accounts are missing. In this case there is no removal event. My process tries to closely simulate this by purging evolution data. This may be more of an enhancement to the backup/restore than a bug. Here are my thoughts, The backup needs to include the Online Account information by default. The restore wizard might additionally prompt for a merge and/or overwrite of existing Online Accounts and would likely need to generate new tokens (re-OAuth).. Assuming Online accounts has proper hooks for these activities. An interim solution might be to present the previous Online Account configuration and launch the Online Accounts dialog for the user to configure on their own. (to simply resolve the bug with no consideration for the user experience) I do not have a strong opinion on if it is necessary to properly handle offline data from online accounts in the case that somebody is trying to get back data they no longer have online access to, or to handle the case where the tokens may still be valid and the user has an expectation that re-authentication is not necessary. I do notice that my auth tokens are preserved when I remove and re-create google online accounts via Evolution directly, but that is not the case when remove and re-create via Online Accounts, so there is precedent for either behavior with respect to preserving tokens. I think re-auth should be required so that evo backups cannot become a backdoor to Online information.
Evolution is only one consumer of Gnome Online Accounts, the right place to backup your GOA accounts is GOA itself. I would open a bug report against it. From evolution's point of view is not much difference between restoring from a backup and running evolution when the previously configured online account had been removed meanwhile, or even the respective support was disabled (like if you disable mail only and keep using calendar/contacts). The backup/restore only restores to a certain state and the next evolution run is done migration, if needed. The function on create-goa-account-on-demand seems to be goa_provider_add_account(), still, as one consumer of many, I still feel like goa itself is the right place for this. (In reply to comment #3) > I do notice that my auth tokens are preserved when I remove and re-create > google online accounts via Evolution directly, but that is not the case when > remove and re-create via Online Accounts, so there is precedent for either > behavior with respect to preserving tokens. I think re-auth should be > required so that evo backups cannot become a backdoor to Online information. These tokens and passwords are stored in keyring, that's why they are preserved. There are not in the backup itself in any form. I tend to WontFix this unless the missing goa accounts aren't removed completely after restore.
The stated issue is the case, if you backup with GOA accounts, and then restore the backup without those GOA accounts, you forever receive the following message until those accounts are restored. Cannot find a corresponding account in the org.gnome.OnlineAccounts service from which to obtain an authentication token.
It may be worth noting that my version of "without those accounts" is having removed them in the GOA interface and I am not sure if the GOA remove purges all keys/tokens.
If there are Evolution data sources that reference a GOA account ID, but no such GOA account is found, then Evolution is supposed to destroy those data sources. Sort of like garbage collecting. Evolution's GOA module already garbage collects data sources on startup, but I guess we also need to somehow signal it to garbage collect immediately after restoring data sources from a backup. The EShell:event signal should do the trick for this. The backup plugin could issue an "event::data-restored" signal which the GOA module could listen for and re-run its garbage collecting routine.
So I guess this is NEW based on comment #7.
Similar downstream bug report from 3.4.1: https://bugzilla.redhat.com/show_bug.cgi?id=821667 The reported get same error only when editing mail account (configured through Online Accounts) in evolution. I would try to address this issue together with yours, as they seem to be closely related. From the downstream bug report: --------------------------------------------------------------------------- Description of problem: I get the message: "Cannot find a corresponding account in the org.gnome.OnlineAccounts service from which to obtain an authentication token." Version-Release number of selected component (if applicable): evolution-3.4.1-2.fc17.i686 How reproducible: Always Steps to Reproduce: 1. Add Google on Online Accounts 2. Open Evolution, edit Google's account settings 3. Select "Check for new mail in all folders" 4. Close evolution 5. Reopen evolution Actual results: Error message appears "Cannot find a corresponding account in the org.gnome.OnlineAccounts service from which to obtain an authentication token." Expected results: Should "Check for new mail in all folders" Additional info: Checking or unchecking any other checkbox on "Receiving options" also triggers the error; renaming the account seems to do it as well. "Fix" the issue: 1- Delete 'username@gmail.com' account from Evolution. 2- Close Evolution. 3- Open "Online Accounts" 4- Select "Gmail". 5- Disable and Reenable "Mail". 6- Open Evolution: the account works again.
Hmm, I'm not fully correct, because the initial issue got fixed within bug #672474. The thing is that the goa listener on evolution's side removes goa accounts, but it doesn't save them. I'll open a new bug report for the issue mentioned in the comment #9. *** This bug has been marked as a duplicate of bug 672474 ***
The bug for comment #9 is bug #676226.