629208 - imap save as draft doesn't increment unread count of drafts folder

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[David :Bienvenu]

Attachment: proposed fix

Drafts are now saved as unread, but we're not incrementing the unread count on the imap drafts folder. Patch upcoming.

Comment 1

[David :Bienvenu]

Comment on attachment 507287 [details] [diff] [review]
proposed fix

multiple saves keep incrementing the count, need to figure out why.

Comment 2

[Mark Banner (:standard8)]

David, is this the drafts issue where we aren't showing a draft count until refresh of the folder?

If so marking as blocking 3.3 as I think we're going to need this with the change in the drafts situation.

(In reply to comment #1)
> multiple saves keep incrementing the count, need to figure out why.

Note that when it happens to me, I normally get multiple copies in the drafts folder - it doesn't seem to replace the existing copy.

Comment 3

[David :Bienvenu]

(In reply to comment #1)
> Comment on attachment 507287 [details] [diff] [review]
> proposed fix
> 
> multiple saves keep incrementing the count, need to figure out why.

Yeah, this patch isn't right by itself, because we don't decrement the count for the copy that we delete.

Comment 4

[David :Bienvenu]

(In reply to comment #3)

> Yeah, this patch isn't right by itself, because we don't decrement the count
> for the copy that we delete.

and the reason for that is we don't delete the pseudo-hdrs until the user selects the drafts folder, and we playback the offline events which correspond to the pseudo headers. We could update the drafts folder after saving the message to the draft folder, which would keep everything up to date. Or we could keep track of the fact that we need to delete the original pseudo-hdr when we re-save the draft.

Comment 5

[David :Bienvenu]

Attachment: simple fix

this simply updates the imap drafts folder after doing a save as draft - that keeps everything up to date.

Comment 6

[Mark Banner (:standard8)]

Comment on attachment 524296 [details] [diff] [review]
simple fix

Ok, my brief test shows this as good, and it is what I'd expect the patch to be. So r=Standard8 - lets get this into the tree and we can verify it further.

Comment 7

[David :Bienvenu]

fixed on trunk - http://hg.mozilla.org/comm-central/rev/3109ba7f3a36, patch in bug had a bit of cruft from a previous patch.