GNOME Bugzilla – Bug 235201
Add per-contact default folder for "Move to" or "Sent Mail"
Last modified: 2012-06-16 12:02:38 UTC
Description of Problem: When reading mail, I would like an action "Move to [default] folder". Where [default] is a per-contact setting. This could either be a new setting in the contacts, or based on existing settings such as nickname, or firstname. I am a user migrating to evolution from pine, and in pine I use the setting "saved-msg-name-rule = by-nick-of-from" I guess a similar effect could be acheived using filters, but I can't see how to do this without setting up a new filter rule for every contact. For dealing with sent-mail a default FCC option would help.
I'm not absolutely sure this is a duplicate of bug 201892... please REOPEN if you don't feel this correct. *** This bug has been marked as a duplicate of 201892 ***
I don't believe this is a duplicate of 1892. I would like to make it possible to define a "default folder" for the "move to folder..." action based on (for example) the nickname of the contact. Maybe this could be overriden on a per-contact folder. In other words, if I have a contact with the nickname "Rob". When I right click on a mail from "Rob" I would like to see, a "Move to Default Folder (Rob)" option next to the "Move to folder...." option. This action would also appear in the filters dialog, which would allow the use of a single rule. I don't believe you could acheive this (even with bug 201892) without manually defining a filter rule for every single contact.
I'm looking for something close enough to this to post here instead of filing a new request: ou can set up filters, and you have the option of saying whether filters take effect when email arrives. What I would like is to have two sets of filters. First, keep the current system. Second, add a second set called "filing rules." When a message is displayed, the filing rules would be checked, and if there is a match, an icon would be displayed with the name of the folder that the rule says to move the message to. Then when the user decides he is done with the message, he just hits that button and the message is filed in the appropriate folder. For example, I may receive mail from two different lists in my inbox, and when I'm done with them, I want to archive them in different folders. With this feature, I could just hit one button or key sequence for each message and it would be moved to the correct folder. Any work-around that involves applying filters as they exist now won't work, as most people use filters for incoming mail before reading it (to put spam away and such). This is for after messages are read. Doing this on a per-contact basis would work, but I would prefer general filter rules.
added eplugin keyword ignore the last comment since that is a different feature (re-file that if you like, but i would guess it already exists).
Bumping version to a stable release.
I would also like to see this feature: the lack of it in Evolution is why I still send a lot of mail to individuals using Alpine, although Evolution is better for many other purposes. The important point about this feature is that it: (1) applies only to mails that are being sent, or (2) is invoked on selected message(s). It is not filtering that rearranges already-filed mail on the server according to a set of rules. Alpine offers filtering which is similar to Evolution's, as well as the Fcc: functionality, which illustrates that they are seen as distinct. (FWIW, the Alpine docs also say that using server-side functionality if available is a better way of doing this, which I tend to agree with.) Evolution allowing just one folder per account for saving copies of all sent messages is restrictive and gets in the way of handling e-mail correspondence efficiently. (This is also an aspect of bug 246514.) It would be nice to see an improvement of functionality in this area.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 210450 ***