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

NEW
Unassigned

Status

MailNews Core
Backend
--
enhancement
17 years ago
3 months ago

People

(Reporter: Garth Wallace, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gs], URL)

(Reporter)

Description

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

Comment 1

17 years ago
helpwanted
Assignee: selmer → nobody
Keywords: helpwanted

Updated

17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

13 years ago
Blocks: 236849

Comment 2

13 years ago
*** Bug 240601 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey

Updated

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

Comment 3

12 years ago
*** Bug 101886 has been marked as a duplicate of this bug. ***

Comment 4

12 years ago
*** Bug 233187 has been marked as a duplicate of this bug. ***

Comment 5

12 years ago
*** Bug 320794 has been marked as a duplicate of this bug. ***

Comment 6

12 years ago
Bug 233187 comment 2 has an interesting idea towards implementing the backend part of this feature.

Comment 7

11 years ago
any progress on this?

Comment 8

11 years ago
*** Bug 358988 has been marked as a duplicate of this bug. ***

Comment 9

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

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

Updated

10 years ago
Duplicate of this bug: 380149

Updated

10 years ago
Priority: P3 → --

Updated

10 years ago
Duplicate of this bug: 392656
Duplicate of this bug: 404072

Comment 14

10 years ago
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??

Updated

10 years ago
Duplicate of this bug: 37332

Updated

9 years ago
QA Contact: backend

Updated

9 years ago
Duplicate of this bug: 259040
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core

Comment 17

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

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

9 years ago
Mail internal values is a good default; overriding the default threading is the issue here.

Comment 20

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

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

9 years ago
There are prefs for that - mail.strict_threading, and mail.thread_without_re. Totally unrelated to this bug though.

Comment 23

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

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

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

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

Comment 28

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

Comment 29

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

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

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

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

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

Comment 34

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

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

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

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

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

9 years ago
(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...
Duplicate of this bug: 479452
Duplicate of this bug: 485037
Duplicate of this bug: 536431
Duplicate of this bug: 566595
http://getsatisfaction.com/mozilla_messaging/topics/keeping_bob_together
Keywords: helpwanted
Whiteboard: [gs]

Comment 46

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

Updated

5 years ago
Duplicate of this bug: 751596

Comment 48

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

4 years ago
Good news: With the addon "TotalMessage" you can customize threadings (beside many other things you can do with it -> http://totalmessage.mozdev.org/

Comment 50

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

Comment 51

11 months ago
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

4 months ago
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

3 months ago
As #259040 has been resolved as a duplicate of this, this item should also keep splitting "false" threads in mind.
You need to log in before you can comment on or make changes to this bug.