After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 371590 - filter action "set status read" doesn't work
filter action "set status read" doesn't work
Status: RESOLVED WONTFIX
Product: evolution
Classification: Applications
Component: Mailer
2.8.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 604385 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-11-06 16:36 UTC by owen-bugs
Modified: 2009-12-13 13:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description owen-bugs 2006-11-06 16:36:59 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:
Comment 1 André Klapper 2006-11-09 01:11:05 UTC
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... :-)
Comment 2 owen-bugs 2006-11-10 14:05:53 UTC
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)
Comment 3 André Klapper 2006-11-10 14:29:45 UTC
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... ;-)
Comment 4 owen-bugs 2006-11-10 15:41:15 UTC
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.
Comment 5 Jeffrey Stedfast 2006-11-10 16:02:27 UTC
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)
Comment 6 owen-bugs 2006-11-10 16:32:25 UTC
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.
Comment 7 André Klapper 2009-12-13 13:16:47 UTC
*** Bug 604385 has been marked as a duplicate of this bug. ***