301084 - Option to file replies in folder of original message

Status: VERIFIED FIXED

(MailNews Core :: Composition, enhancement)

Description

[Jens Bannmann]

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.

Comment 1

[Jens Bannmann]

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).

Comment 2

[Emil Hesslow]

Attachment: A patch

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.

Comment 3

[Emil Hesslow]

Attachment: The GUI change

Comment 4

[Adam Guthrie]

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

Comment 5

[David :Bienvenu]

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.

Comment 6

[David :Bienvenu]

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.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: discussion with jwz about how the References header, forwarding, and threading interact

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.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 10

[Jens Bannmann]

(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.

Comment 11

[David :Bienvenu]

Attachment: mark appended messages read, unless getting appended to drafts

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

Comment 12

[David :Bienvenu]

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)

Comment 13

[David :Bienvenu]

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

Comment 14

[Emil Hesslow]

Attachment: patch v1.1

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.

Comment 15

[Alexey N. Solofnenko]

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

Comment 16

[Emil Hesslow]

Attachment: patch v1.2

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 17

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 18

[Emil Hesslow]

Attachment: Patch 1.3

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

Comment 19

[Jens Bannmann]

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?

Comment 20

[Emil Hesslow]

Attachment: Patch 1.4

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

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 22

[Emil Hesslow]

Attachment: Patch 1.5

Got r+ from dmose on IRC.

Comment 23

[David :Bienvenu]

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.

Comment 24

[David :Bienvenu]

Attachment: add ability to set msg flags at the time of calling CopyFileMessage

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 25

[David :Bienvenu]

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

Comment 26

[David :Bienvenu]

ok, last patch checked in to fix forumzilla regression.

Comment 27

[Jens Bannmann]

Attachment: Patch 1.5 - backend part

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

Comment 28

[Jens Bannmann]

Attachment: Patch 1.5 - frontend part

Carrying over r=dmose.

Comment 29

[David :Bienvenu]

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...

Comment 30

[Jens Bannmann]

Attachment: backend part, v1.6

applied bienvenu's suggestions.

Comment 31

[David :Bienvenu]

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 : "");

Comment 32

[Jens Bannmann]

Attachment: backend part - v1.7 (checked in on trunk)

Carrying over r=dmose, sr=bienvenu.

Comment 33

[Roland Stuehmer]

Bug 177040 should probably be set a dupe of this.

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

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

this attachment is now checked in on trunk

Comment 35

[Jens Bannmann]

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

Comment 36

[Scott MacGregor]

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.

Comment 37

[Stephen]

(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?

Comment 38

[Daniel Bachran]

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 ;)

Comment 39

[Jens Bannmann]

(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.

Comment 40

[Daniel Bachran]

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 :)

Comment 41

[dsmart]

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 [e-mail], 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.

Comment 42

[Jerry Baker]

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.

Comment 43

[David Fraser]

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

Comment 44

[Jerry Baker]

> 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"?

Comment 45

[dsmart]

(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. 

Comment 46

[jan honsberg]

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....)

Comment 47

[David :Bienvenu]

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

Comment 48

[Shailesh Kochhar]

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 49

[Scott MacGregor]

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.

Comment 50

[Eugene Savitsky]

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

Comment 51

[Scott MacGregor]

Attachment: updated front end patch (checked in on the trunk)

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

Comment 52

[Scott MacGregor]

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 53

[Scott MacGregor]

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.

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 55

[Jens Bannmann]

(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...

Comment 56

[Jens Bannmann]

(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 57

[Mike Connor [:mconnor]]

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

bumping approval request to the new flag

Comment 58

[Scott MacGregor]

Attachment: patch synched up to the 1.8.1 branch

Comment 59

[Scott MacGregor]

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

I moved this request to another patch.

Comment 60

[Scott MacGregor]

Comment on attachment 222415 [details] [diff] [review]
updated front end patch (checked in on the trunk)

I moved this request to another patch.

Comment 61

[Scott MacGregor]

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. 

Comment 62

[Eyal Rozenberg]

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.

Comment 63

[Jerry Baker]

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

Comment 64

[Daniel Kabs, reporting bugs since 2002]

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

Comment 65

[Magnus Melin [:mkmelin]]

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

Comment 66

[Igor Stirbu]

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.

Comment 67

[Igor Stirbu]

Attachment: Adds FCC3 for placing replies in original's message folder

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.

Comment 68

[Magnus Melin [:mkmelin]]

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.

Comment 69

[Igor Stirbu]

(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.