GNOME Bugzilla – Bug 659729
Upgrade breaks search folders
Last modified: 2012-05-31 12:10:33 UTC
I have several search folders configured to operate on multiple IMAPx Inboxes by specifying the Inboxes as Specific Folders in the Search Folder Sources. After upgrading from 2.32 to 3.1.91 in each of the search folder properties I see a reference to my old evolution account that was not migrated during the setup and the search folder does not operate. It appears similar to below immediately following upgrade: email:1234567890.1234.1@hostname/INBOX The workaround is to recreate the folder after which it appears as: folder:/INBOX Previously it was shown in 2.32 as: imapx:accountname@hostname/INBOX
(In reply to comment #0) > After upgrading from 2.32 to 3.1.91 How exactly did you upgrade? Did a restoring of a backup take place?
Initially I did upgrade without taking a backup. Shortly after upgrading, I did do a backup and restore in 3.1.91 to test it. So I did one along the way in 3.1.91, and I did not check search folders prior to this restore. The reason I did not create a backup is that I cloned my current Ubuntu 11.04 system to test the 11.10 beta which does a 2.32 upgrade to 3.1.91 along the way. I have my current 2.32 (daily driver) which the upgrade was based off, and a couple of backups from shortly after the upgrade. I can purge my .cache .local .camel-certs .config .gconf of evolution 3.1.91, restore my 2.32 file structures and re-test an upgrade (if that is equivalent). When I created the clone and upgraded 11.04/2.32 I had not moved to imap+ yet, which I have now completed in 2.32 for all my IMAP accounts, so perhaps the showing as imapx: is not exactly how it was before the upgrade as I just peeked at my current 2.32 config to get the 2.32 example.
confirmation in downstream bug report
Patch on related bug seems to correct this on 3.2.0 on current Ubuntu 11.10 B2 https://bugzilla.gnome.org/show_bug.cgi?id=659726
I retested my 2.32 data upgrade with the above mentioned patch, and search folders and Draft/Sent folder mappings are now preserved going from 2.32 (Ubuntu 11.04) to 3.2.0 (Ubuntu 11.10 B2) with IMAP+ accounts.
I have the same as in comment #1 using 3.2.0 from Ubuntu Oneric. After upgrade the specific folders like email:1234567890.1234.1@hostname/INBOX do not work anymore. Deleting them from the vfolder definition and trying to re-add them gives folder:/INBOX. However adding my 3 imapx inboxes I get: folder:/INBOX folder:/INBOX folder:/INBOX Only the e-mail from 1 imapx inbox is filtered, the other 2 are ignored. This seems logical from the syntax which does not specify the account for the inbox. Result is: for me the vfolder function has become useless. I used it to merge different accounts and split into a vfolder for each customer. Ferry
Ah ha! This must be what happened to me too. I recently upgraded to Fedora 16 which moved from Evolution 3 to 3.2. My vfolders now see email from one account but not any of the others.
(In reply to comment #7) > Ah ha! This must be what happened to me too. I recently upgraded to Fedora 16 > which moved from Evolution 3 to 3.2. > > My vfolders now see email from one account but not any of the others. Same for me after upgrade to Fedora 16. VFolders show mail only from one of three selected accounts.
Just tested that upgrading from evolution-3.2.2 to 3.2.3 (from Fedora 16 updates-testing) fixes the problem.
Thanks for a bug report. I see multiple issues mentioned here. a) missing migration code for search folders, which Ian found as bug #659726 b) incorrect folder uris, which, based on comment #3, should be fixed during move from 3.2.2 to 3.2.3, though, according to 3.2.3 NEWS file, the bug #659726 made it just in 3.2.2 of evolution and I do not see any relevant change for 3.2.3. Marek, is it possible you moved from 3.2.1 to 3.2.3? Or maybe the migration routine was triggered only after 3.2.3 upgrade. Anyway, I understand from above comments that all issues are fixed now and the this is supposed to be a duplicate of bug #659726, thus I'm marking this as such. *** This bug has been marked as a duplicate of bug 659726 ***