Open Bug 36024 Opened 24 years ago Updated 2 years ago

ability to customize thread association (mark rcv'd message as reply to arbitrary message)

Categories

(MailNews Core :: Backend, enhancement)

Product:
MailNews Core
Component:
Backend
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: gwalla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [gs]) 

This came up on n.p.m.mailnews:

   From: "David A. Cobb" <superbiskit@home.com>
   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.
helpwanted
Assignee: selmer → nobody
Keywords: helpwanted
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 236849
*** Bug 240601 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
QA Contact: lchiang
Summary: [RFE] ability to customize thread view → ability to customize thread association (mark rcv'd message as reply to arbitrary message)
*** Bug 101886 has been marked as a duplicate of this bug. ***
*** Bug 233187 has been marked as a duplicate of this bug. ***
*** Bug 320794 has been marked as a duplicate of this bug. ***
Bug 233187 comment 2 has an interesting idea towards implementing the backend part of this feature.
any progress on this?
*** Bug 358988 has been marked as a duplicate of this bug. ***
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.
(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.
Priority: P3 → --
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??
QA Contact: backend
Product: Core → MailNews Core
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?
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?
Mail internal values is a good default; overriding the default threading is the issue here.
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?
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.
There are prefs for that - mail.strict_threading, and mail.thread_without_re. Totally unrelated to this bug though.
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).
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.
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.
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.
Tom
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...
I got here from one of the dups; can't remember which one.
I was looking for exactly what is described in http://kb.mozillazine.org/Stop_threading_by_subject 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.
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).
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?).
(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.
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...
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)
Questions:
- 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.
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
(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
(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
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.
(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.
(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.
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...
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!
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.
Good news: With the addon "TotalMessage" you can customize threadings (beside many other things you can do with it -> http://totalmessage.mozdev.org/
Thanks, Dominik, but this add-on doesn't seem to work under OS X.
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!
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.
As #259040 has been resolved as a duplicate of this, this item should also keep splitting "false" threads in mind.

(In reply to Ken Weingold from comment #50)

Thanks, Dominik, but this add-on doesn't seem to work under OS X.

...and TB 69 :)

Worth adding that mutt appears to be able to do this (move defective message — actually, any message — into the thread specified by the user).

As I understand it, the problem is that people seem to be able to tolerate split threads, and most users don't even understand what a thread is (they think it's a Subject line).

I can confirm that mutt can indeed do this, both to push a message INTO an existing thread AND to move a message OUT OF a thread to stand on its own. As the code for mutt is publicly available, adding this facility to Tbird (or any other MUA) would be possible.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.