Closed Bug 210566 Opened 22 years ago Closed 21 years ago

SEND LATER fails to set the REPLIED or FORWARDED status (flag) on the message

Categories

(MailNews Core :: Composition, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: joe, Assigned: sspitzer)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 It you SEND LATER an email message with the REPLY button the REPLIED flag in the inbox does not get set. Neither does it get set when the mail is actually sent. Reproducible: Always Steps to Reproduce: 1.Reply to an email. 2.Click SEND LATER. 3.The status remains Read and does not change to Replied. 4.When you actually click FILE>SEND UNSENT MESSAGES, the status of the original mail remains READ. Actual Results: See above. Expected Results: Either when you click SEND LATER or when you actually send the reply to an email, the status should change to REPLIED.
Duplicated with 1.4 Final, Windows 2000. This is also true for forwarding. I couldn't find any exact dupes, altho the symptom about forwarding is mentioned in bug 60795. Confirming; updating summary to mention 'forward' and 'status'
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: REPLY then SEND LATER fails to set the REPLIED flag in mail inbox → SEND LATER fails to set the REPLIED or FORWARDED status (flag) on the message
Duplicated with 1.6b Linux. Probably this can be marked as a dupe of bug #128996? I believe these two bugs have the same cause. If a Mail is not sent directly but temporarily stored in another Folder (e.g. Drafts as in bug #128996) the Status of the replied Mail remains read. You can set the OS Field to All, I think...
*** Bug 220333 has been marked as a duplicate of this bug. ***
Confirmed with a tree built 2004-apr-15. This bug is ***very*** annoying. I replied to dozens of mails flying from Paris to SF today, sent them when I arrived at my hotel, and the status is still only "read" :-/ Given the fact it's the only of keeping track easily of the mails one has replied to, I think this is a severe bug for mailbox management.
Isn't this a dup of Bug 103732? But that was fixed before the last comments in this bug. It could be a regression, because I know this feature worked after david fixed it.
It is fixed in 1.8 Alpha, at least for the "SEND LATER" case. I have not noticed it fixed in prior editions
Which other case does this bug cover??? David fixed it so that the 'replied' status is set at the time the message is actually sent. And it already worked in 1.5.
(In reply to comment #7) > Which other case does this bug cover??? David fixed it so that the 'replied' > status is set at the time the message is actually sent. The "other case" would be sending a draft -- bug 128996. My bad for not finding bug 103732 when looking for dupes at comment 1. I'm not sure whether I tested this with a 1.6x build, when I made the dupe at comment 3. This does WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040710 Markus Moebs, Daniel Glazman -- is this bug still a problem for you with current builds?
works for me in 1.8A2
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
I get this using the Magic SLR to delay sending until I want to. Using TB 17.0.3. After writing a message, click Send Later, so it stays in Outbox. Then file the original message to a folder. Then do Get/Send to flush the Outbox. No "Replied" arrow appears. Same goes for Forwarding. This is VERY VERY annoying, as I nearly always file my messages after replying. It's impossible to tell if I've replied to people ! Regards Nigel
Nigel, try not moving the original message before the reply/forward is really sent out. TB maintains a link to the original message so it can mark it with the icon once the reply is sent, but it probably isn't omnipotent to follow the message anywhere you move it.
You need to log in before you can comment on or make changes to this bug.