Option to file replies in folder of original message

VERIFIED FIXED in mozilla1.8beta4

Status

enhancement
VERIFIED FIXED
14 years ago
10 years ago

People

(Reporter: jens.b, Assigned: hesslow)

Tracking

({verified1.8.1})

Dependency tree / graph
Bug Flags:
blocking-thunderbird2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(8 attachments, 9 obsolete attachments)

24.23 KB, image/png
Details
11.02 KB, text/html
Details
943 bytes, patch
mscott
: superreview+
benjamin
: approval1.8b4+
Details | Diff | Splinter Review
18.05 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
14.38 KB, patch
jens.b
: superreview+
Details | Diff | Splinter Review
6.22 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
17.93 KB, patch
Details | Diff | Splinter Review
11.77 KB, patch
Details | Diff | Splinter Review
Reporter

Description

14 years ago
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.
Reporter

Updated

14 years ago
Assignee: mscott → jens.b
Reporter

Comment 1

14 years ago
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).
Reporter

Updated

14 years ago
Assignee: jens.b → hesslow
Assignee

Comment 2

14 years ago
Posted patch A patch (obsolete) — Splinter Review
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.
Assignee

Comment 3

14 years ago
Posted image The GUI change

Comment 4

14 years ago
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

14 years ago
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

14 years ago
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.
Reporter

Comment 10

14 years ago
(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

14 years ago
this should fix the general case, unless the target fcc folder is the drafts
folder, which is pretty unlikely.
Attachment #189712 - Flags: superreview?(mscott)

Updated

14 years ago
Attachment #189712 - Flags: superreview?(mscott) → superreview+

Comment 12

14 years ago
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)
Attachment #189712 - Flags: approval1.8b4?

Updated

14 years ago
Attachment #189712 - Flags: approval1.8b4? → approval1.8b4+
Assignee

Comment 14

14 years ago
Posted patch patch v1.1 (obsolete) — Splinter Review
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.
Assignee

Updated

14 years ago
Attachment #189610 - Attachment is obsolete: true
Attachment #189933 - Flags: review?(dmose)
Is it possible to have the setting per-folder or at least for all folders,
except Indox (the later is in Outlook)?
Assignee

Comment 16

14 years ago
Posted patch patch v1.2 (obsolete) — Splinter Review
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 ).
Attachment #189933 - Attachment is obsolete: true
Attachment #189968 - Flags: review?(dmose)
Attachment #189933 - Flags: review?(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.
Attachment #189968 - Flags: review?(dmose) → review-
Assignee

Comment 18

14 years ago
Posted patch Patch 1.3 (obsolete) — Splinter Review
I think this takes care of all thinks you took up in the last review.
Attachment #189968 - Attachment is obsolete: true
Attachment #190254 - Flags: review?(dmose)
Reporter

Comment 19

14 years ago
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?
Assignee

Updated

14 years ago
Attachment #190254 - Flags: review?(dmose)
Assignee

Comment 20

14 years ago
Posted patch Patch 1.4 (obsolete) — Splinter Review
jensb: You're right. I changed it for testing purpose. In this new patch I
changed it to false.
Attachment #190254 - Attachment is obsolete: true
Attachment #190257 - Flags: review?(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.
Assignee

Comment 22

14 years ago
Posted patch Patch 1.5 (obsolete) — Splinter Review
Got r+ from dmose on IRC.
Attachment #190257 - Attachment is obsolete: true
Attachment #190421 - Flags: review+
Assignee

Updated

14 years ago
Attachment #190421 - Flags: superreview?(mscott)
Attachment #190257 - Flags: review?(dmose)

Comment 23

14 years ago
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

14 years ago
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.
Attachment #190750 - Flags: superreview?(mscott)

Comment 25

14 years ago
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

Updated

14 years ago
Attachment #190750 - Flags: superreview?(mscott) → superreview+

Updated

14 years ago
Attachment #190750 - Flags: approval1.8b4?

Updated

14 years ago
Attachment #190750 - Flags: approval1.8b4? → approval1.8b4+

Comment 26

14 years ago
ok, last patch checked in to fix forumzilla regression.
Reporter

Updated

14 years ago
Attachment #190421 - Flags: superreview?(mscott)
Reporter

Comment 27

14 years ago
Posted patch Patch 1.5 - backend part (obsolete) — Splinter Review
Splitting patch into backend and frontend part. Carrying over r=dmose.
Attachment #190421 - Attachment is obsolete: true
Attachment #192235 - Flags: superreview?(bienvenu)
Attachment #192235 - Flags: review+
Reporter

Comment 28

14 years ago
Posted patch Patch 1.5 - frontend part (obsolete) — Splinter Review
Carrying over r=dmose.
Attachment #192236 - Flags: superreview?(mscott)
Attachment #192236 - Flags: review+

Comment 29

14 years ago
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...
Attachment #192235 - Flags: superreview?(bienvenu) → superreview-
Reporter

Comment 30

14 years ago
Posted patch backend part, v1.6 (obsolete) — Splinter Review
applied bienvenu's suggestions.
Attachment #192235 - Attachment is obsolete: true
Attachment #192266 - Flags: superreview?(bienvenu)
Attachment #192266 - Flags: review+

Comment 31

14 years ago
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 : "");
Attachment #192266 - Flags: superreview?(bienvenu) → superreview+
Reporter

Comment 32

14 years ago
Carrying over r=dmose, sr=bienvenu.
Reporter

Updated

14 years ago
Attachment #192266 - Attachment is obsolete: true
Attachment #192272 - Flags: superreview+
Attachment #192272 - Flags: review+
Attachment #192272 - Flags: approval1.8b4?

Comment 33

14 years ago
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
Attachment #192272 - Attachment description: backend part - v1.7 → backend part - v1.7 (checked in on trunk)
Reporter

Comment 35

14 years ago
*** Bug 177040 has been marked as a duplicate of this bug. ***
Reporter

Updated

14 years ago
Component: Message Compose Window → MailNews: Composition
Flags: review-
Flags: review+
Product: Thunderbird → Core
Target Milestone: --- → mozilla1.8beta4

Updated

14 years ago
Blocks: 11039

Updated

14 years ago
Whiteboard: pendging mscott's approval evaluation

Comment 36

14 years ago
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.
Attachment #192272 - Flags: approval1.8b4? → approval1.8b4-

Comment 37

14 years ago
(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

14 years ago
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 ;)
Reporter

Comment 39

14 years ago
(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

14 years ago
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

14 years ago
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.

Updated

14 years ago
Whiteboard: pendging mscott's approval evaluation → pending mscott's approval evaluation

Comment 42

14 years ago
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

14 years ago
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

14 years ago
> 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"?

Updated

14 years ago
Flags: blocking-thunderbird2?

Comment 45

14 years ago
(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

13 years ago
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

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

Comment 48

13 years ago
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

13 years ago
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.
Attachment #192236 - Flags: superreview?(mscott) → superreview+

Updated

13 years ago
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Whiteboard: pending mscott's approval evaluation

Comment 50

13 years ago
How could I test it? Is it in the trunk nightlies?

Comment 51

13 years ago
I updated the front end patch to include my review comments and to remove some hard tabs I found in the file.
Attachment #192236 - Attachment is obsolete: true
Attachment #222415 - Flags: superreview+

Updated

13 years ago
Attachment #222415 - Attachment description: updated front end patch → updated front end patch (checked in on the trunk)

Comment 52

13 years ago
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.
Attachment #222415 - Flags: approval-branch-1.8.1?

Comment 53

13 years ago
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.
Attachment #192272 - Flags: approval-branch-1.8.1?(mscott)
Attachment #222415 - Flags: approval-branch-1.8.1? → approval1.8.1?
Attachment #192272 - Flags: approval-branch-1.8.1?(mscott) → approval1.8.1?
Attachment #222415 - Flags: approval1.8.1? → approval-thunderbird2?
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.
Reporter

Comment 55

13 years ago
(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...
Reporter

Comment 56

13 years ago
(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
Attachment #192272 - Flags: approval1.8.1? → approval-thunderbird2?

Comment 58

13 years ago
Attachment #229276 - Flags: approval-thunderbird2?

Comment 59

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

I moved this request to another patch.
Attachment #192272 - Flags: approval-thunderbird2?

Comment 60

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

I moved this request to another patch.
Attachment #222415 - Flags: approval-thunderbird2?

Updated

13 years ago
Attachment #229276 - Flags: approval-thunderbird2? → approval-thunderbird2+

Comment 61

13 years ago
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. 
Keywords: fixed1.8.1
Reporter

Updated

13 years ago
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 62

13 years ago
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

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

Updated

13 years ago
Blocks: 345121
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. ***
Status: RESOLVED → VERIFIED

Comment 66

12 years ago
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

12 years ago
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.

Comment 69

12 years ago
(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.

Updated

11 years ago
Duplicate of this bug: 382693
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.