Closed Bug 254589 Opened 20 years ago Closed 16 years ago

Filter that moves message from IMAP to another account does not perform other filter actions (Mark as Junk, Set Priority, Label)

Categories

(MailNews Core :: Filters, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: milo, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040805 Firefox/0.9.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040805 Firefox/0.9.3 When I add a filter that moves the message to another folder and also marks it as read, the message is moved, but it is not marked as read. Reproducible: Always Steps to Reproduce: 1. Create a filter that moves the message to another folder and also marks it as read 2. Send a message to yourself that gets filtered Actual Results: The message is moved to the chosen folder, but it has status unread. Expected Results: It should have been marked as read... :-) Thunderbird 0.5, 0.6 and 0.7 - 0.7.3 has this bug. IMAP server: Debian sarge/testing /usr/sbin/imapd
*** Bug 254773 has been marked as a duplicate of this bug. ***
Confirming on a recent branch CVS build on WinXP. I only see it if I'm moving to a folder on another account. But this seems to affect all filter actions: if you have a filter set up to move a message to a folder on another account, no other filter action (mark as read, mark as junk, ...) is performed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: Message filter action "mark the message as read" doesn't work when also moving the message → Filter that moves message to another account does not perform any of the other filter actions (mark as read, mark as junk, ...)
Does the problem occur when moving to another IMAP account, or only to a local (or POP account) folder? I see the symptom of failing to mark read when moving from my fastmail.fm IMAP account to a local folder, but I don't have another IMAP account to check against.
Summary: Filter that moves message to another account does not perform any of the other filter actions (mark as read, mark as junk, ...) → Filter that moves message from IMAP to another account does not perform any of the other filter actions (mark as read, mark as junk, ...)
It happens when moving from IMAP to IMAP as well (that's where I saw it).
(In reply to comment #3) > Does the problem occur when moving to another IMAP account, or only to a local > (or POP account) folder? It fails for me (message is not marked as read) when filter moves the message from IMAP inbox to local folder. The "Delete the message" + "Mark the message as read" combination also fails, i.e. IMAP inbox to IMAP trash. When moving messages to a user-created folder within the same IMAP account the Folders display indicates new mails in that folder (folder name in bold font plus number of new messages within parenthesis), but when I open the folder the messages are marked as read and the folder name in the Folders display is changed back to indicate no unread messages (normal font). I don't know if that's a bug or a feature. ;-)
I was testing IMAP notifications today, with a filter to Move the message to a Local Folder and Mark read. I noticed that if the delete model for the account is Mark As Deleted, then the moved (actually copied) message is properly marked Read. In this case, the folder still gets a New flag (see bug 230805), and if you're using a Classic-based theme, that will mean the folder is bolded; this last point is described at bug 201917 comment 14. At any rate, this bug is not limited to Thunderbird (unsurprisingly). Besides TB0.7, I see this symptom with Moz 1.7.2 and 1.8a3-0824.
OK, really moving it now.
Component: General → Filters
Product: Thunderbird → MailNews
Version: unspecified → Trunk
*** Bug 232185 has been marked as a duplicate of this bug. ***
Following the suggestion at the duplicate bug, I created a filter log, which says that the message *is* marked as read before being moved. I suspect this bug should be in Networking:IMAP rather than Filtering.
*** Bug 258435 has been marked as a duplicate of this bug. ***
*** Bug 251908 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
For the Mark As Read case, I am not seeing this bug with current nightlies of TB; possibly was fixed by the patch for bug 261297. (Jeonkyu Kim, is that possible?) Milo, are you still seeing the symptom with current builds?
(In reply to comment #12) > For the Mark As Read case, I am not seeing this bug with current nightlies of > TB; possibly was fixed by the patch for bug 261297. (Jeonkyu Kim, is that > possible?) > Hello Mike, Sorry for late response. :-) My patch fixed missing special flags such as junk status, label and priority when message is copied to IMAP folder. So, it might solve part of this issue, but 'mark as read' action is not related to the patch. However, I also could not reproduce problem of the action. It worked well with my latest build.
Blocks: 161658
(In reply to comment #12) > For the Mark As Read case, I am not seeing this bug with current nightlies of > TB; possibly was fixed by the patch for bug 261297. (Jeonkyu Kim, is that > possible?) > > Milo, are you still seeing the symptom with current builds? Just reconfirming what I posted on bug 161658 - with a fresh build (20050604) I still see a problem. Mark as Read and Flag works, Mark as Junk, Set Priority, and Label don't work in IMAP.
Updating summary per comment 14.
Summary: Filter that moves message from IMAP to another account does not perform any of the other filter actions (mark as read, mark as junk, ...) → Filter that moves message from IMAP to another account does not perform other filter actions (Mark as Junk, Set Priority, Label)
Assignee: mscott → nobody
QA Contact: filters
the junk part may be bug 384853.
Status: NEW → ASSIGNED
Product: Core → MailNews Core
I'll look at this as part of my preservation of message metadata work.
Assignee: nobody → kent
Severity: normal → major
On current trunk builds, I can no longer reproduce any of the symptoms of this bug, so I am going to mark it as WFM. There has been a lot of work on preserving message metadata during moves and copies, and I believe they have fixed the issues of this bug.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Assignee: kent → nobody
You need to log in before you can comment on or make changes to this bug.