Many users file incoming messages to topic-specific folders (with filters or manually). When replying to such messages, Thunderbird always places the reply in one folder (normally the "Sent" folder of the account). It should optionally be able to override this when replying to messages and file the reply in the folder of the original message instead.

For the record, the existing fcc UI (place copy in...) isn't sufficient here, because it still places a copy in the "Sent" folder, and because it's cumbersome to manually select the original folder (that is opened and known anyway).

The only problem that I know of is that on IMAP-account is your reply marked as unread and I can't figure out why. That is probably it own bug because I had the same problem when I wrote an extension that set compFields.fcc.

Bug 263112 is pretty similiar to this. The only difference is that it requests the ability to do the same thing with forwarded messages.

re the msg getting marked unread, in general, newly appended messages to imap folders are unread, so you have to do something special to get them marked read. I think in the case of fcc the way that usually works is that when we append the message, we add the /SEEN flag at append time. I think we pass the flags in when we do the append msg from file using the copy state...but I don't know why the additional fcc would be different. It should not be hard to fix, however.

this is why it works for the sent folder: http://lxr.mozilla.org/mozilla/source/mailnews/imap/src/nsImapMailFolder.cpp#4634 so we need to do something special for this bug. I'll think about it.

Since jwz once spent a bunch of time thinking about this stuff, I asked for his opinion about how the References header, forwarding, and threading interact. I've attached this conversation with permission.

*** Bug 263112 has been marked as a duplicate of this bug. ***

This bug is really a DUP of bug 177040. That bug has had a whole bunch of other bugs DUPed against it. It's worth reading through those various DUPed bugs, as they provide some useful use cases, as well as suggested preferences verbiage.

(In reply to comment #9) > This bug is really a DUP of bug 177040. From the description of bug 177040 it looks like the reporter doesn't propose filing the message to the original folder _instead_ of the "sent" folder, which is what this bug is about (i.e. one of the goals is to not have to clean up your sent folder so often). Its duplicates, however, sound more like this bug. Should the other bug be duped against this one? It's bad style, I know, but it seems work will happen here.

this should fix the general case, unless the target fcc folder is the drafts folder, which is pretty unlikely.

Comment on attachment 189712 [details] [diff] [review] mark appended messages read, unless getting appended to drafts this will enable the other patch in this bug to work, but it will do the right thing in either case (i.e., it stands on its own)

patch in attachment 189712 [details] [diff] [review] checked in.

This patch only takes care of when you reply to a mail not forwards. This because we do not set the reference-header for forwarded mails and because of that they are not sorted into threads.

Is it possible to have the setting per-folder or at least for all folders, except Indox (the later is in Outlook)?

This makes sure that not place the message in the original message folder if it is a newsgroup and rss-account ( because that don't work ). It also checkes to see if we can put the message in the folder ( canFileMessages-flag ).

Comment on attachment 189968 [details] [diff] [review] patch v1.2 In general, this looks great! Most of my comments are just minor nits. >Index: mail/locales/en-US/chrome/messenger/am-copies.dtd >=================================================================== >RCS file: /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/am-copies.dtd,v >retrieving revision 1.3 >diff -u -r1.3 am-copies.dtd >--- mail/locales/en-US/chrome/messenger/am-copies.dtd 22 Mar 2005 12:13:40 -0000 1.3 >+++ mail/locales/en-US/chrome/messenger/am-copies.dtd 17 Jul 2005 18:01:47 -0000 >@@ -4,6 +4,7 @@ > <!ENTITY sendingPrefix.label "When sending messages, automatically: "> > <!ENTITY fccMailFolder.label "Place a copy in:"> > <!ENTITY fccMailFolder.accesskey "P"> >+<!ENTITY fccReplyFollowsParent.label "Place replies in the folder of the message replied to"> How about in "the message being replied to"? Also, since it looks like you've made a bunch of your changes to both Thunderbird and Seamonkey, you may wish to make this one to the Seamonkey version too. >Index: mailnews/base/prefs/resources/content/am-copiesOverlay.xul >=================================================================== >RCS file: /cvsroot/mozilla/mailnews/base/prefs/resources/content/am-copiesOverlay.xul,v >retrieving revision 1.4 >diff -u -r1.4 am-copiesOverlay.xul >--- mailnews/base/prefs/resources/content/am-copiesOverlay.xul 1 Feb 2005 15:28:15 -0000 1.4 >+++ mailnews/base/prefs/resources/content/am-copiesOverlay.xul 20 Jul 2005 21:10:38 -0000 >@@ -85,7 +85,7 @@ > prefstring="mail.identity.%identitykey%.fcc" > oncommand="setupFccItems();"/> > </hbox> >- <radiogroup id="doFcc"> >+ <radiogroup id="doFcc"> > <grid class="specialFolderPickerGrid"> > <columns> > <column/> >@@ -115,7 +115,13 @@ > </rows> > </grid> > </radiogroup> >- >+ <hbox align="center" class="fccReplyFollowsParent" hidable="true" hidefor="nntp,rss"> >+ <checkbox wsm_persist="true" id="identity.fccReplyFollowsParent" >+ label="&fccReplyFollowsParent.label;" >+ prefattribute="value" >+ prefstring="mail.identity.%identitykey%.fccReplyFollowsParent" >+ observes="broadcaster_doFcc"/> >+ </hbox> It looks to me like the prefstring here uses the interCaps version of the name like the interface does rather than the underscore_separated_version like other pieces of the code do for the pref. After you fix this, be sure to test that the right thing is really happening here. >Index: mailnews/compose/public/nsIMsgSend.idl >=================================================================== >RCS file: /cvsroot/mozilla/mailnews/compose/public/nsIMsgSend.idl,v >retrieving revision 1.39 >diff -u -r1.39 nsIMsgSend.idl >--- mailnews/compose/public/nsIMsgSend.idl 13 Jun 2005 18:10:19 -0000 1.39 >+++ mailnews/compose/public/nsIMsgSend.idl 20 Jul 2005 19:07:32 -0000 >@@ -53,6 +53,7 @@ > #include "domstubs.idl" > #include "nsIPrompt.idl" > #include "MailNewsTypes2.idl" >+#include "nsIMsgComposeParams.idl" > > %{C++ > #include "nsIURL.h" >@@ -203,7 +204,9 @@ > in nsIDOMWindowInternal parentWindow, > in nsIMsgProgress progress, > in nsIMsgSendListener aListener, >- in string password >+ in string password, >+ in string originalMsgURI, >+ in MSG_ComposeType type > ); In general, when adding new params to idl these days, it's preferred to pick use either AUTF8String or ACString, as they will allow, under certain circumstances, string sharing to happen. > { >- char *uri = GetFolderURIFromUserPrefs(nsMsgDeliverNow, mUserIdentity); >- if ( (uri) && (*uri) ) >+ // Only check if the user wants the message in the original message folder >+ // if the msgcomptype is some kind of a reply. >+ if (strlen(originalMsgURI) > 0 && ( >+ type == nsIMsgCompType::Reply || >+ type == nsIMsgCompType::ReplyAll || >+ type == nsIMsgCompType::ReplyToGroup || >+ type == nsIMsgCompType::ReplyToSender || >+ type == nsIMsgCompType::ReplyToSenderAndGroup || >+ type == nsIMsgCompType::ReplyWithTemplate ) >+ ) Didn't we decide in IRC that not to do this for news replies? I think this should allow us to eliminate three of the types here. > { >- if (PL_strcasecmp(uri, "nocopy://") == 0) >- mCompFields->SetFcc(""); >+ nsCOMPtr <nsIMsgAccountManager> accountManager = do_GetService(NS_MSGACCOUNTMANAGER_CONTRACTID, &rv); >+ if (NS_SUCCEEDED(rv) && accountManager) Unless you have some specific reason to believe otherwise (ie there's a comment in the IDL that says so, or it's apparent from reading the C++ implementation), checking NS_SUCCEEDED(rv) should be sufficient for XPCOM getters. No need to check that the pointer is non-null. This applies to the other gets in the patch as well. >+ { >+ nsCOMPtr<nsIMsgAccount> account; >+ rv = accountManager->GetAccount(mAccountKey.get(), getter_AddRefs(account)); >+ if (NS_SUCCEEDED(rv) && account) >+ { >+ nsCOMPtr <nsIMsgIncomingServer> incomingServer; >+ rv = account->GetIncomingServer(getter_AddRefs(incomingServer)); >+ if (NS_SUCCEEDED(rv) && incomingServer) >+ { >+ nsXPIDLCString incomingServerType; >+ rv = incomingServer->GetCharValue("type", getter_Copies(incomingServerType)); >+ if (NS_SUCCEEDED(rv) && incomingServerType && >+ !incomingServerType.Equals("rss") && >+ !incomingServerType.Equals("nntp")) >+ { >+ PRBool fccReplyFollowsParent = PR_FALSE; No need to preinitialize a variable before calling a getter to write into it if you're not going to use the variable if the getter fails.

I think this takes care of all thinks you took up in the last review.

Comment on attachment 190254 [details] [diff] [review] Patch 1.3 >+pref("mail.identity.default.fcc_reply_follows_parent", true); Didn't we decide in #maildev to default this to false?

jensb: You're right. I changed it for testing purpose. In this new patch I changed it to false.

Comment on attachment 190257 [details] [diff] [review] Patch 1.4 Please make sure any lines that you've added wrap at < 80 columns, if you would. With that change, r=dmose. Please request sr from mscott, as he's probably the most likely to catch any XUL issues.

Got r+ from dmose on IRC.

my checkin broke the readness handling of extensions that append messages to imap folders from a file. So I need to figure out some other way of doing this, probably by figuring out a way of making the fcc code set a flag in the copy state that says to mark the message read.

this allows the caller of copyFileMessage to specify new msg flags, which is needed because there's no source message to get the headers from.

Comment on attachment 190750 [details] [diff] [review] add ability to set msg flags at the time of calling CopyFileMessage one nice thing about this patch is that it now allows us to retain the msg flags on imap messages that have attachments detached/deleted

ok, last patch checked in to fix forumzilla regression.

Splitting patch into backend and frontend part. Carrying over r=dmose.

Carrying over r=dmose.

Comment on attachment 192235 [details] [diff] [review] Patch 1.5 - backend part need new uuid for nsIMsgIdentity and nsIMsgSend.idl you can use nsMsgUtils.h's GetMsgDBHdrFromURI to get the msg db hdr. Then you wouldn't need to include nsIMsgMessageService.h (but you might need nsMsgUtils.h) Instead of getting the incoming server from the account, could you just get it from the msgHdr.folder.server? That would cut down on the number of lines of code, I think...

applied bienvenu's suggestions.

Comment on attachment 192266 [details] [diff] [review] backend part, v1.6 thx, Jen. a couple nits, which it's up to you if you want to address: if you move the CanFileMessages check up earlier, then you don't need to check for "nntp" because nnto can't file messages. and this can be: + if (PL_strcasecmp(uri, "nocopy://") == 0) + mCompFields->SetFcc(""); + else + mCompFields->SetFcc(uri); mCompFields->SetFcc(PL_strcasecmp(uri, "nocopy://") ? uri : "");

Carrying over r=dmose, sr=bienvenu.

Bug 177040 should probably be set a dupe of this.

Comment on attachment 192272 [details] [diff] [review] backend part - v1.7 (checked in on trunk) this attachment is now checked in on trunk

*** Bug 177040 has been marked as a duplicate of this bug. ***

Comment on attachment 192272 [details] [diff] [review] backend part - v1.7 (checked in on trunk) this enhancement is best developed on the trunk. Too late in the game for us to start exploring this for 1.5. I'm also not happy with the UI yet, am still thinking about alternatives.

(In reply to comment #36) > (From update of attachment 192272 [details] [diff] [review] [edit]) > this enhancement is best developed on the trunk. Too late in the game for us to > start exploring this for 1.5. I'm also not happy with the UI yet, am still > thinking about alternatives. > I notice that the GUI only allows one to keep replies in the same folder as the original message. Will it also be possible to keep forwarded messages in the same folder as the original?

I'll have the same question as spl above: the GUI screenshot (https://bugzilla.mozilla.org/attachment.cgi?id=189611) says "place replies in the folder of the message replied to", but is the patch only addressing replies or also forwarded messages? About the UI and possible alternatives: We already have two choices in the GUI, 1) "Sent" Folder on, 2) Other. Why add a 3rd, different method (checkbox) to choose the folder? Why not just add another pseudo-entry in the "Other" listbox which reads: Other: "Original message folder" I admit that this may not be as discoverable by end users as a separate checkbox, though... But then, why not keep only one listbox which contains all possible choices? Example: +----------------------------------+ Place a copy in: | "Sent" Folder on emil.hesslow [v] | "Sent" Folder on aaa.bbb | | | Original message folder | | +----------------------------------+ ciao, daniel ;)

(In reply to comment #38) > is the patch only addressing replies or also forwarded messages? It only applies to replies. > Why add a 3rd, different method (checkbox) to choose the folder? > Why not just add another pseudo-entry in the "Other" listbox which reads: > Other: "Original message folder" That won't work because not every message *has* an original message. If a user chose your pseudo-entry, what happens with messages that are not replies? IMO, options for regular messages and replies (perhaps including forwards) need to be separate.

Ah, right. Makes sense. Funny how strange those brilliant ideas look when you check them out the next morning, isn't it? *grin* Well, you're right. It makes sense to have different settings for regular messages and for replies/forwards. But then, why are there two listboxes to specify where regular messages are saved? Well, this doesn't belong into this bug anyways... I'd like to ask why forwarded messages are not included in this patch? Is this on purpose or is there a different bug on storing forwarded messages together with their original messages? Why should we handle them differently to replies? ciao, daniel :)

I'm not sure that this needs to be messed with. The filters in TB are a bit restrictive otherwise filters could be used for this. e.g. I am a recent Eudora Pro (Paid mode) refugee and I have just spent the better part of the day migrating over nine years of emails to TB 1.5RC3. While I was duplicating my filters, I realized that the TB filters only worked on incoming mails, not outgoing. Thats highly restrictive. If filters would work on outgoing mails, then a filter could be made to add replies to the originating folder or wherever. e.g. In this shot from a EudoraPro filter, any message sent to or replied from that contains webmaster@3000ad.com, will be saved in the 'Webmaster' folder. http://www.3000ad.com/temp/tb301084.png Also, when To and From messages are in the same folder, the From messages are in italics. This helps to differentiate them from each other. So, I think that if the filters were extended to support From messages, then this problem would be solved and the confusion seen in this thread would be moot.

Is this feature intended to be permanent, or just a stopgap measure until we can filter outgoing messages? The two would seem redundant, and this feature only addresses half of the issue of keeping mail organized by recipient.

Re Comment 42: For me, having the ability to file replies in the same folder as the original message would be much more helpful than filtering outgoing messages. Not all the filters that apply to the incoming message would neccessarily apply to the response (e.g. Sender would be different). Also if messages have been manually filed its still desirable to keep their replies with them, but this would not be accomplished with automatic filters

> Not all the filters that apply to the incoming message would neccessarily > apply to the response. Hence the idea of outgoing mail filters, not one set of filters for incoming and outgoing. > Also if messages have been manually filed its still desirable to keep their > replies with them, but this would not be accomplished with automatic filters Why not? Make a filter that says "FCC to the current folder"?

(In reply to comment #44) > > Why not? Make a filter that says "FCC to the current folder"? > ....well, because that would be too easy I suppose.

i don't know: is this an bug only for the Mozilla-Suite or for Seamonkey and Thunderbird too? I would like to have this in sm, but in tb it will be great too. if there is an possibility to write this enhancement, who would need an motivation? (for our in-company-developers we use jelly babys for motivation....)

*** Bug 330764 has been marked as a duplicate of this bug. ***

I used Eudora for a long time and the way they handled this was to automatically add a BCC entry which would look something like: BCC: f/Mail/Folder/SubFolder/SubSubFolder The "f" at the beginning of the BCC line implied that the BCC was not to an email address but to a folder in the mailbox. This worked well and had the added advantage of being very flexible - while composing a reply it was easy to change where it would be filed an to add other folders as well. If I get hold of Eudora sometime, I'll post a screenshot.

Comment on attachment 192236 [details] [diff] [review] Patch 1.5 - frontend part when I made comment 36 I was trying to come up with something along the lines of what Daniel proposed in comment 38 but obviously that doesn't work because it's for replies only. I don't see any way of combining it with the other menu lists. So that being said, on to the existing UI patch. 1) The white spacing here looks wrong + var type = parent.getAccountValue(account, accountValues, + "server", "type", + null, false); + hideShowControls(type); 2) Remove this rule from all 4 CSS files: +.fccReplyFollowsParent { + margin-left: 20px; +} The reply option is not part of the "place a copy in" radio control group, so it shouldn't be indented along side those options. Thank you for your patience on this and I'm sorry it took me so long. I also think after we get this on the trunk for a little while we should consider the back end and front end patches for 1.8.1.

How could I test it? Is it in the trunk nightlies?

I updated the front end patch to include my review comments and to remove some hard tabs I found in the file.

Comment on attachment 222415 [details] [diff] [review] updated front end patch (checked in on the trunk) I'll approve this once the front end has baked on the trunk for a bit.

Comment on attachment 192272 [details] [diff] [review] backend part - v1.7 (checked in on trunk) I'll approve this once the front end has baked on the trunk for a bit.

What's the policy for interface changes for mailnews? We generally aren't taking interface changes like this on the 1.8 branch unless they're unavoidable or really-high-benefit.

(In reply to comment #54) > What's the policy for interface changes for mailnews? We generally aren't > taking interface changes like this on the 1.8 branch unless they're unavoidable > or really-high-benefit. I thought interface and feature improvements are what Thunderbird 2.0 is all about...

(In reply to comment #53) > I'll approve this once the front end has baked on the trunk for a bit. Hey Scott, just wanted to remind you of this bug so it doesn't get off the radar before the freeze.

Comment on attachment 192272 [details] [diff] [review] backend part - v1.7 (checked in on trunk) bumping approval request to the new flag

Comment on attachment 192272 [details] [diff] [review] backend part - v1.7 (checked in on trunk) I moved this request to another patch.

Comment on attachment 222415 [details] [diff] [review] updated front end patch (checked in on the trunk) I moved this request to another patch.

This is fixed on the branch and the trunk. I also went over this change with the enigmail extension folks and they were ok with it too.

IIRC, the patch makes this a global setting... but, surely, it must be a per-folder setting! I mean, one will probably want this for some topical folders, but not for, say, the Inbox, or some non-topical folders.

If 11039 ever gets fixed this bug, and its solution, will be irrelevant. You might want to keep an eye on that one.

I agree with Eyal Rozenberg, "keep replies in this folder" should be a "per folder" setting, not a global one. For example "kmail" works this way. Please see "Folder Properties" on http://docs.kde.org/stable/en/kdepim/kmail/folders.html

*** Bug 362794 has been marked as a duplicate of this bug. ***

I've stumbled on the issue of reply copies and found first the bug 359545. https://bugzilla.mozilla.org/show_bug.cgi?id=359545 The commit 1.375 added support for copies in original message's folder. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsMsgSend.cpp&branch=1.391&root=/cvsroot&subdir=mozilla/mailnews/compose/src&command=DIFF_FRAMESET&rev1=1.374&rev2=1.375 This issue is not yet closed and I would ask several questions that might help me to contribute to the feature: - In reply #39: not every message *has* an original message -- how one would be able to reply to a non-existing message? What is a "pseudo-entry"? - Is it reasonable to add MSG_FCC3_HEADER_ID for keeping the original message folder? The code from commit 1.375 should be changed to leave the code dealing with "Sent" copies alone and add separate code for dealing with FCC3 similar to the one for FCC2. I think this will make the code cleaner and easier to maintain. The layout should be corrected (as mentioned in comment #49): [X] Save a copy of sent messages (*) "Sent" Folder on: [Local Folders |v] ( ) Other: [Sent on Local Folders |v] [X] Place replies in the folder of the message being replied to and remove the observes="broadcaster_doFcc" for the checkbox from copies overlay.

Added FCC3 for handling separately "Place replied in the folder of the message being replied to" from FCC. Changed the UI to reflect the functionality.

Igor, I assume that patch should be in bug 359545, or in a new bug. This one is closed. If you want to get it in, you also have to ask review by setting the r? flag to a suitable reviewer.

(In reply to comment #68) > Igor, I assume that patch should be in bug 359545, or in a new bug. This one is > closed. If you want to get it in, you also have to ask review by setting the r? > flag to a suitable reviewer. Thanks for the comment. I'll upload the patch in bug 359545 and ask for review.