Last Comment Bug 36024 - ability to customize thread association (mark rcv'd message as reply to arbitrary message)
: ability to customize thread association (mark rcv'd message as reply to arbit...
Status: NEW
Product: MailNews Core
Classification: Components
Component: Backend (show other bugs)
: Trunk
: All All
-- enhancement with 39 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 37332 101886 233187 240601 259040 320794 358988 380149 392656 404072 479452 485037 536431 566595 751596 (view as bug list)
Depends on:
Blocks: 236849
  Show dependency treegraph
Reported: 2000-04-16 22:27 PDT by Garth Wallace
Modified: 2017-02-21 09:04 PST (History)
51 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Garth Wallace 2000-04-16 22:27:06 PDT
This came up on n.p.m.mailnews:

   From: "David A. Cobb" <>
   Newsgroups: netscape.public.mozilla.mail-news
   Subject: [Wishlist] Threading issues
   Date: Sun, 16 Apr 2000 20:20:05 -0400

   I subscribe to many discussion lists and the ability of the mail
   client to thread the incoming mail is vital.  People, or their
   mailers, sometimes mess up the thread data when they reply: either
   they change the subject or drop tags.

   It would be very helpful if I could edit thread associations at
   least in my own message-store: "this one is related to that one" or,
   especially when the sender assigned no subject, "this one is NOT
   related to that one."

Basically this would mean being able to drag an messagee over another in the
thread view, and have it "connect" to the latter as if it were a reply, or drag
an article away from its position as a reply to another message. It would
require some way of maintaining the user-defined relationships and applying them
whenever the appropriate newsgroup is viewed.
Comment 1 User image lchiang 2000-04-17 13:57:53 PDT
Comment 2 User image Bogdan Stroe 2004-04-22 21:53:56 PDT
*** Bug 240601 has been marked as a duplicate of this bug. ***
Comment 3 User image Mike Cowperthwaite 2005-12-19 07:04:37 PST
*** Bug 101886 has been marked as a duplicate of this bug. ***
Comment 4 User image Mike Cowperthwaite 2005-12-19 07:09:13 PST
*** Bug 233187 has been marked as a duplicate of this bug. ***
Comment 5 User image Mike Cowperthwaite 2005-12-19 07:09:54 PST
*** Bug 320794 has been marked as a duplicate of this bug. ***
Comment 6 User image Mike Cowperthwaite 2005-12-19 07:11:45 PST
Bug 233187 comment 2 has an interesting idea towards implementing the backend part of this feature.
Comment 7 User image Konstantin Svist 2006-07-06 13:46:34 PDT
any progress on this?
Comment 8 User image Magnus Melin 2006-11-09 12:39:51 PST
*** Bug 358988 has been marked as a duplicate of this bug. ***
Comment 9 User image Sin Kimishima 2007-03-22 21:50:40 PDT
Chances are, people prefer different algorithms (such as Fw should be included in the thread, whilst others don't). It might be better if an extension was created where you could merge/cut mail threads.
Comment 10 User image Susanne Jaeger 2007-03-23 00:26:59 PDT
(In reply to comment #9)

As I understand this RFE it's not about algorithm for automatic changing, but about adding ability to manually change association. 

Comment 11 User image Magnus Melin 2007-05-15 12:07:38 PDT
*** Bug 380149 has been marked as a duplicate of this bug. ***
Comment 12 User image Magnus Melin 2007-09-09 08:39:42 PDT
*** Bug 392656 has been marked as a duplicate of this bug. ***
Comment 13 User image Phil Ringnalda (:philor) 2007-11-16 13:53:43 PST
*** Bug 404072 has been marked as a duplicate of this bug. ***
Comment 14 User image kamal kapur 2007-11-23 10:53:36 PST
just going thru the history because my bug (404072) was marked as a duplicate of this one. What a surprise! Is it so difficult that it has not been resolved for more than 7 years??
Comment 15 User image Magnus Melin 2008-01-05 06:16:00 PST
*** Bug 37332 has been marked as a duplicate of this bug. ***
Comment 16 User image Magnus Melin 2008-06-30 06:49:31 PDT
*** Bug 259040 has been marked as a duplicate of this bug. ***
Comment 17 User image Gunther 2008-09-19 06:00:53 PDT
What about something with a sqlite backend just like the "places.sqlite" from firefox? I'm not sure if the messages must be threaded by mail-internal-values or by setting/saving thread-tags locally. 
Just drag some messages together, "set as thread" (or whatever to be named), generate a small table-entry with "[message-id] = [thread-id], [message-id2] = [thread-id]".
This way it would be possible to deselect messages from a thread without changing the mails themselves.

What do you think?
Comment 18 User image SiKing 2008-09-19 09:00:14 PDT
Threading must not require user-input to make it work! I have over 13k mails (pieces, not bytes!) in my mailbox, I am not going to re-thread everything manually.
What is wrong with using the mail internal values?
Comment 19 User image Konstantin Svist 2008-09-19 09:54:48 PDT
Mail internal values is a good default; overriding the default threading is the issue here.
Comment 20 User image SiKing 2008-09-19 12:08:13 PDT
From my observations (I have not look at any code), I get the impression that currently mail is threaded based on the internal values AND the mail Subject. I personally would like to override the Subject part.
Or am I completely wrong here?
Comment 21 User image Konstantin Svist 2008-09-19 12:36:19 PDT
You're not wrong, but there are too many people in the mailing lists who don't know anything about message threading -- and reply to existing thread. Even if they change the subject, Thunderbird files the new mail as part of the thread.
It's very messy.
You're not at all wrong about messy subject threading. My mother sometimes sends me messages without a subject, while my boss likes to send me subject "FYI" way too often. Needless to say, it's very annoying.
Comment 22 User image Magnus Melin 2008-09-21 02:33:59 PDT
There are prefs for that - mail.strict_threading, and mail.thread_without_re. Totally unrelated to this bug though.
Comment 23 User image Konstantin Svist 2008-09-21 11:14:02 PDT
It's not enough to be able to turn it off for everything at once. I want more fine-grained control than that.
This is not a task where the end result is clearly defined (like sorting) -- this is a case where the end result exists only in the head of the user (similar to determining if a message is spam), so computer can never get it right 100% of the time. It should stop trying. It gets it right 98% of the time (as far as I'm concerned), and I'm okay with that; I'm willing to finish the other 2% (and many others are willing to live with 98% as long as its simple & consistent).
Comment 24 User image Gunther 2008-09-22 01:47:13 PDT
IMHO I thought this thread is about a feature-request for manually-threading/tagging (technically) unrelated emails (regarding subjects, mail-headers and so on).
Scenario: I'm working in big projects with lots of people, and I'm getting lots of emails, Cc or forwarded as a result of requests of my colleagues. These emails are technically spoken unrelated but: It is difficult to keep the overall view over let's say 100 emails that are about just about 10 tasks, but listed in 80 threads. So if you could manually add single mails to existing threads you could keep the whole situation in control as you won't have to keep in mind what mail belongs to what task/thread.
If I'm completely wrong or the idea of my picture here is unclear, please give me a notice. Thanks.
Comment 25 User image kamal kapur 2008-09-22 02:24:11 PDT
Gunther has hit the nail squarely on the head. The whole idea is to be able to link unrelated mails into a thread - similar to putting them in a common folder. Threading will be preferred over a folder because, hopefully, it will allow linking / threading messages by user choice.
Comment 26 User image Thomas Hedden 2008-09-22 04:34:46 PDT
I didn't see anyone mention this; please
forgive me if I missed someone else's post.
One feature of customized threading that
would be very nice would be the capability
of including a message in more than one
thread simultaneously. From the user's
perspective, this might, but need not,
involve creating a "copy" of (actually a
link/shortcut to) the message.
The motivation is that people often address
multiple issues in a single message. (I've
learned not to do this in my own messages,
because otherwise if there is one issue
that gets a delayed response, it often
holds up answers to the other issues in
the message.) However, it is common for
e-mail messages to belong to multiple threads.
Comment 27 User image Onno Ekker [:nONoNonO UTC+1] 2008-09-22 05:03:30 PDT
I'd like to be able to keep using strict threading (on message-id and references headers), but also to overrule this:
- split thread in case someone hits reply but it isn`t a reply
- merge thread in case someone sends a mail with outlook that doesn't use references header or whenever I get a mail from bugzilla, which in most cases references messages not in my mailbox...
Comment 28 User image SiKing 2008-09-22 08:58:35 PDT
I got here from one of the dups; can't remember which one.
I was looking for exactly what is described in using the mail.strict_threading and mail.thread_without_re configs (also suggested by Magnus above). Except they don't seem to do for me what it says on the box.

I have like a hundred completely unrelated discussion in my mailbox with Subject "(no subject)", for example. Currently they are all threaded together, even though they have no common References or In-Reply-To headers. I would like to unthread them.
Comment 29 User image richlv 2008-09-22 09:00:59 PDT
re: comment #28 - i had to restart thunderbird & rebuild index for mailboxes to make these params change anything (you can rebuild index from folder properties).
Comment 30 User image SiKing 2008-09-22 09:17:56 PDT
re: comment #29: that did it for me. Thank You!
All these undocumented features. Now if I could only figure out what the mail.strict_threading _actually_ does. But that is no longer related to this bug (or thread?).
Comment 31 User image Thomas Nygreen 2008-09-22 16:45:38 PDT
(In reply to comments #24, #25 & #26)
Let's not make this into a tagging issue. A good tagging system is a good idea, but that's a whole different request. This is a request for the ability to join threads that are broken, and to break threads that should have been broken, as if the messages had come with the correct headers.

Changing the headers is a bit messy, but why not? It has to be the simplest way.
Comment 32 User image Konstantin Svist 2008-09-22 17:39:01 PDT
I agree. Definitely better than keeping this info in the index or some separate db that might break (I don't want to re-thread all messages after reindexing!)
Old headers can be "backed up" if that's an issue at all...
Comment 33 User image Gunther 2008-09-29 03:03:14 PDT
Ok, to sum up the discussion:
- needed functionality: manually assign/de-assign mails to threads to enhance existing thunderbird automagic-threading-mechanism
- where to store thread-information: mail-header (messy, but better than external source)
- Is this correct? (In)Complete?
- If complete and correct: Who can code something like that? As I am no coder I can't estimate effort to do this.
Comment 34 User image Gunther 2008-09-29 12:50:29 PDT
mutt has such a feature - as far as my wishes go:
1.) first "t" to tag a single mail (that you wish to add to another thread)
2.) then "&" to add the tagged mail to the current mail (generates a thread if none existed)
I haven't checked how it's done in technical/coder sense - but it's nice
Comment 35 User image Gunther 2008-09-30 03:00:44 PDT
(In reply to comment #34)
mutt stores the information in such way that the manually-generated thread becomes visible if you re-check your IMAP-folder with thunderbird
Comment 36 User image Thomas Nygreen 2008-10-01 02:43:09 PDT
(In reply til comment #35)
That means mutt is adding/altering headers

I have also been thinking about the scope of the changes you do to the threads. It would be confusing if you use Thunderbird on different computers and get different threading. It would also be unacceptable to have to redo all the rethreading on all machines. If you use different programs it would also be nice if they used the same threading.

My conclusion: alter the mail-headers
Comment 37 User image Matthias Bobzien 2008-10-01 03:20:48 PDT
Forgive me if I'm talking nonsense, I'm just a Mozilla user.

Rather than changing header entries of 'In-Reply-To:' and 'References:' etc., wouldn't it be possible to add extended headers (similar to the 'X-Mozilla-Status:') and let Thunderbird evaluate these headers? 

e.g. 'X-In-Reply-To:' or 'X-References:' or something like this? If present, these headers would override the original headers and used by Thunderbird for threading.
Comment 38 User image Thomas Nygreen 2008-10-01 04:45:21 PDT
(In reply to comment #37)
Seems like a good idea. That would give the same threading on different locations, and it would be a lot less messy than changing the original headers.
Comment 39 User image Thomas Nygreen 2008-10-01 04:55:33 PDT
(In reply to my own comment #38)
The advantage of changing the reference header over using a custom header is that when you reply to a message which you have manually threaded, your reply will also contain references to the previous messages in the thread, and so it will also be threaded correctly, even for other users.

This can also be solved by storing the manual threading as a custom header (not messing up the original, which is good), and when you reply to or forward the message, we fix the reference header of the outgoing message.
Comment 40 User image Onno Ekker [:nONoNonO UTC+1] 2008-10-01 06:52:29 PDT
The advantage of using a new (X-References?) header is that it can also work if the user threads on subject instead of reference header. New behavior could be to thread on X-header if it is present and based on users prefs otherwise.

I'm not totally sure though if it is a good idea to also allow manual changing of threads when you thread on subject. Things might get confusing that way...
Comment 41 User image Phil Ringnalda (:philor) 2009-02-20 09:29:24 PST
*** Bug 479452 has been marked as a duplicate of this bug. ***
Comment 42 User image Mark Banner (:standard8) 2009-03-24 13:35:03 PDT
*** Bug 485037 has been marked as a duplicate of this bug. ***
Comment 43 User image Phil Ringnalda (:philor) 2009-12-22 14:23:56 PST
*** Bug 536431 has been marked as a duplicate of this bug. ***
Comment 44 User image Wayne Mery (:wsmwk, NI for questions) 2011-01-14 11:30:26 PST
*** Bug 566595 has been marked as a duplicate of this bug. ***
Comment 45 User image Wayne Mery (:wsmwk, NI for questions) 2011-01-14 11:38:09 PST
Comment 46 User image Bill Hollander 2011-01-14 12:10:10 PST
I would like to cast my vote in favor of adding this functionality: the ability to manually assign/de-assign mails to threads. I would assume that when using different computers that all have IMAP synching the manual threading/de-threading would show up wherever you log in. Yes, go for it. I approve!
Comment 47 User image [:Aureliano Buendía] 2012-06-05 00:49:47 PDT
*** Bug 751596 has been marked as a duplicate of this bug. ***
Comment 48 User image mrudat 2012-12-07 03:46:16 PST
If mutt already does this (presumably by editing the message headers), shouldn't it make sense then to first support however mutt stores the overridden threading information (then document the method and send it off to the IETF), and as a second step implement the thread editing interface.
Comment 49 User image Dominik 2013-02-07 16:01:08 PST
Good news: With the addon "TotalMessage" you can customize threadings (beside many other things you can do with it ->
Comment 50 User image Ken Weingold 2013-02-08 06:19:26 PST
Thanks, Dominik, but this add-on doesn't seem to work under OS X.
Comment 51 User image Klaudiusz Gawlik 2016-07-08 04:10:46 PDT
Hello All
I know that this is very old issue. But I want to refresh them. Any chance to do something in this thread? This is really missing thing!
Comment 52 User image Peter Flynn 2017-02-07 14:53:47 PST
Please let's not allow the real requirement to go out of sight: repairing defective incoming messages so that they will be threaded correctly. "Defective" in this context means "missing the relevant References message-id". The user should be able to click and drag such a message and drop it into the (existing) thread where it belongs — the display must indicate the potential drop-point with a highlighted line between messages while the message is being dragged, and must recognise when the message is being dropped after the last message in an existing thread (append-to-thread) as distinct from between two messages (insert-into-thread). The add-on must then rewrite (or add) the References header so that it gives the correct list of message-ids required to make the message appear in the thread correctly. That's all. No additional functionality is required.
Comment 53 User image Tilman Vogel 2017-02-21 09:04:38 PST
As #259040 has been resolved as a duplicate of this, this item should also keep splitting "false" threads in mind.

Note You need to log in before you can comment on or make changes to this bug.