GNOME Bugzilla – Bug 341777
"Set Status" filter just doesn't work
Last modified: 2012-02-27 10:38:30 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/evolution/+bug/38477 "I have a rule in Evolution that goes like this: When any message with "SRC:" in the subject line comes in, do the following: - Move it to FolderX - Set its status to "read" The first part works just fine - but the second part, setting the status to "read", has never worked. All of the messages are still in bold, still showing as unread. ... > Thanks for your bug. That works fine for me. What version of Ubuntu do you use? Do you use the filter on a local or imap account? ... Dapper, all packages updated about five minutes ago (Tuesday, April 18, 3:36PM Central Standard Time [USA]). This pair of filters are set for the Evolution Exchange server at my place of employment. (PS: Exchange works FAR better under Dapper than it ever did in Breezy. I daresay its awesome.) ... > is that issue exchange specific maybe? ... No, doesn't seem to be. Created a new filter with the same rules applying to a POP account - same result. I have screenshots, as soon as I figure out how to add them I can show you..." It does the same with GNOME 2.14.1 on imap
would be interesting to know if it worked in the other order: - Set its status to "read" - Move it to FolderX
it works fine when changing the order
haha, i already expected that. :-) (doesn't mean that i know *why* it works the other way round, though.)
you have to set status first so that the "moved" copy also has the attributes, otherwise it won't.
it's confusing for users, if setting a status after moving doesn't work the filter list should now allow to do that
setting the status after the move DOES work, just does not affect the message in the destination folder because that copy has already been delivered to another folder. think of it like this: if you chose the following actions in a filter being applied to messages being downloaded from a POP server, what would you expect? - Copy to folder FooBar - Mark message as Important - Copy to folder BarBaz Answer: - an unaltered copy is in FooBar - an important copy is in BarBaz - the original message (but marked as important) is in Inbox that's why you can't just go flagging all copies of the message with a flag set AFTER the copy was made.
but in that case the message is moved, there is only one message for the user why shouldn't it be marked?
how do we know later filters won't affect the message and copy/move the message? or change attributes? or... ? we don't. a move filter action is really the same as a folder copy, except that it prevents the message from *also* being delivered to Inbox. in the case of filtering messages "on-demand", a move is still a copy, but at the end of the filter matching process, the message is then marked as Deleted.
fair enough. I still think there is some usuability issue on the move case, it's not clear for an user than a move == copy with delete and looks like that user expected the moved message to be the same and then get it marked as read. Anyway you are upstream and I understand you have other issue to fix, I'll comment pointing to your explanations to the distribution bug
Requesting re-open and treating this as a bug. Reason: The user clearly requests the actions: 1) move the message 2) mark it as a read Maybe this doesn't work because of Evolution internals, but it cannot be expected from a user to read Evolution source code or Bugzilla entries to find out why this doesn't work. Additionally, I have met SEVERAL people who told me about this bug. User-unfriendlyness like calling such behaviour a feature not a bug is what prevents people who are not hackers from using their computer's mail client. Please see the Gnome User Interface Guidelines 2.0 "Put the User in Control": "A user should always feel in control, able to do what they want when they want." In this case that means: a) either Evolution should do what the user requests, or b) if this is *really* not possible, inform the user (giving feedback)
*** This bug has been marked as a duplicate of bug 620139 ***