GNOME Bugzilla – Bug 371590
filter action "set status read" doesn't work
Last modified: 2009-12-13 13:16:47 UTC
Please describe the problem: This is a bug that's very old, but I thought I should finally submit it. I move all my spam into a folder marked Assassinated thanks to SpamAssassin, but I would also like to automatically the spam as read. I should be able to "set status" "read" as one of the filter actions, but it's never worked in over 5 years of using evolution Steps to reproduce: 1. Create a message filter whose action is to set status as read 2. Give it another action to prove that the filter it working 3. let some mail arrive Actual results: The mail should be automatically marked read. Expected results: It's not Does this happen every time? It happens when mail arrives naturally, but I think it works if I specifically run the "apply filters" command. Other information:
wait... do you move and then mark, or do you mark and then move? try it the other way round and tell me if this fixes the issue for you... :-)
yes! If I mark it as read first, and _then_ move it, it works correctly. Thanks! (although this is just a workaround, it's still a bug)
hehehe :-) no, it's not a bug, because "moving" always means that your first copy and then mark the original email as deleted. after moving, you set the "read" status - on the original message, but not on your copy. i know this is tricky, perhaps even a very techie hacker point of view... ;-)
I disagree 100% that this is not a bug. This is exactly the type of low-level technical detail that users should never have to figure out on their own. On a desktop, a move is a move is a move. If on evolution the filter doesn't follow the message to where it moved, it is breaking a basic desktop metaphor. If someone like me who is a software developer and linux admin can't figure this out, how is a regular user supposed to figure it out? I've never reopened a bug before, but I strongly believe that this should be fixed.
it can't be fixed, there's no way to track where the message is after a move (yes, if we kept more context around we could know it is somewhere in folder XYZ, but that doesn't give us enough info to find it in folder XYZ)
Could a UI workaround for this issue be to change the action "move message" to "move message and stop processing?" Although that's wordy, this would indicate to the user that "move message" is a final action that can't be followed by any other actions. Similarly, perhaps "copy to folder" should be renamed "Put a copy in folder" which would also indicate that further actions won't be performed on the copy as well.
*** Bug 604385 has been marked as a duplicate of this bug. ***