GNOME Bugzilla – Bug 215709
vfolder behavior confusing and also described wrong
Last modified: 2013-09-10 14:03:10 UTC
File: usage-mail-organize-vfolders.html Location: Just above Example 4-2. Text: The "Unmatched" vFolder: Obviously, not all messages will fit into all your Virtual Folders. That's why Ximian Evolution includes an Unmatched vFolder. The Unmatched vFolder displays messages that are not matched by other rules. If you have no vFolders, the Unmatched folder will contain all of your mail. Correction: The last sentence is incorrect according to my evolution behaviour which doesn't show any messages in the unmatched folder if I have no vfolders setup. Further to this: Its totally unclear how unmatched behaves if you have multiple vfolders from multiple sources.
The "unmatched" vFolder is terribly confusing, because it has complex and inconsistent behavior. Also, it changed on me without anyone telling me about it. It used to work the way it is now described-- I remember someone complaining that they had not known what a "vFolder" was, opened "UNMATCHED" and, seeing an extra copy of all those emails, just deleted them. Of course, that deleted all their mail and they were very unhappy. Here's how it works now: If you have not created any vfolders, it will be empty, unless you have looked in your trash folder (which is implemented as a vfolder-- that is, it displays all messages you have marked for deletion and not expunged), in which case it will display all your messages. If you have vfolders that search remote mail stores, the unmatched vfolder will search remote stores and display all messages not matched by the vfolders you have created. If you have vfolders, but none of them search remote stores, the unmatched vfolder will not search remote stores and will display only the unmatched local messages. I'm marking this as a 1.1 bug, and assigning it to the mail developers. They should decide whether it is possible to make the behavior of the Unmatched vFolder clearer; if it is not, they will bounce it back to me and I will change the docs. I'm also adding a note about remote store behavior so that at least will be clear.
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
I'm confused, my unmatched contains all my mail (I don't have any vfolders) so what's wrong?
oh, wait...n/m, it contains nothing unless maybe it's still querying all my imap folders or something.
How about we just remove it?
sure, seems that's what everyone wants anyway.
First of all, I use "Unmatched" as my main folder, so please don't remove the functionality. I have only two folders, Inbox and Spam, and lots of vfolders. I was a bit confused when I added Spam as a source for one of my vfolders -- suddenly all the unmatched spam showed up in the Unmatched vfolder. very logical when you think about it, but it put a hamper on my use of Evolution. it would be better if "unmatched" was a criteria available in the vfolder editor. this would also allow me to rename it to something more intuitive, like "personal e-mail". additionally, there would be little reason to keep it as a pre-set vfolder in the tree.
Shouldn't be better to have this depeding on bug 223985 (Unmatched -vfolder rewrite) rather than blocking a UI polish bug?
this can't be fixed for 1.2
Really, I should just rewrite the docs a little more. I think the vFolder behavior itself is fine.
Having clarified the docs a little more, I'm wondering if we can just close this?
sure