Created attachment 892 [details] enhance threading in summary-view to fall back to thread "by common in-reply-to" Hi! Bugzilla uses only an In-Reply-To: Header in it's messages. That means, that if you get on the cc-list for a bug later on, all the Bugzilla messages will be shown unthreaded in your mailbox, as the common 'parent'-message will not be there. Arguably that could be fixed in Bugzilla by referencing all emails with a "reference:" header, but I think the following does make more sense: If 2 messages reply to the same Msg-ID and we can not group them to any message, then group them together making one of the replies the parent. The attached patch fixes the issue with unthreaded bugzilla-messages for me and I think it makes conceptually sense and doesn't break anything...
Hi! Florian, thank you for your patch. I have the same situation with JIRA and Gerrit. If I don't get first 'parent' message then Claws is unable to thread. I've updated your patch to work with current git and I've improved it. Gerrit is worst here: it sends replies with no Message-Id set at all! It may be configuration problem, but this patch handles this as well: If 2 messages reply to the same Msg-ID and we can not group them to any message, then group them together making one of the replies the parent. Parent is an oldest reply of all replies. You can see the diff on github here: https://github.com/SpOOnman/claws/compare/master...threading I also attach an updated patch.
Created attachment 1335 [details] Support threading messages with no direct parent in mbox
Can I have a comment from a developer on this patch?
ok, a quick comment. my view is that what you call an improvement in your patch - "If 2 messages reply to the same Msg-ID and we can not group them to any message, then group them together making one of the replies the parent. Parent is an oldest reply of all replies." - is wrong because neither is the parent.
Thank you Paul fur your comment. Semantically it is wrong, because neither is a parent, you are right. When I have 6 messages with same In-Reply-To header they won't ever get threaded, because I won't receive parent message in future. This patch is a workaround for this scenario. Without this patch I have Bugzilla/JIRA/Gerrit messages, some of them are threaded (when I received original parent) and some of them are loose (e.g. I was invited later to issue/thread/review). This patch doesn't change original, proper behavior, when you have received parent message.
Paul, I don't understand your comment. How do you suggest to visualize the relationship of the messages to the user?
A better solution, imo, was suggested on the users' mailing list: Add a feature that allows the user to re-thread messages, e.g. by drag'n'drop. In this way the user gets control of threading and what the user wants is never assumed.
One possible solution is to add a "in memory" virtual message, or a "on disk" virtual message with the correct message ID and the body like: This message has been created by Claws-Mail to help thread replies correctly. The original message was deleted or not received. The "in memory" virtual message might make things easy for non-threaded view. Or the "on disk" virtual message could be identified and hidden from message lists for non-threaded view. Once this message has been created, the actual threading functionality/logic will work as is. And it would perhaps give the correct context to the threaded level of messages as well.
Getting back to this I think we should get to conclusion. Paul, are you fine with "in memory" message as a virtual root with a body suggested by Abhay?
Is there an interest in this patch? Can I work on it and introduce it as an option?
(In reply to comment #10) > Is there an interest in this patch? Can I work on it and introduce it as an > option? Not really an interest, no. There is now an Actions script in Claws Mail sources which will suffice: http://git.claws-mail.org/?p=claws.git;a=blob;f=tools/cm-reparent.pl;h=9a16da2e3b5c5b1149b9c2e6a5ed135b852383d4;hb=HEAD
Referred action is manual, Paul and it would be cumbersome to thread tens of emails on a daily basis. How do you work on your Bugzilla emails? Do you have them threaded?
(In reply to comment #12) > How do you work on your Bugzilla emails? Do you have them threaded? The original is the parent, the rest are children and are threaded as such. Request a fix in JIRA and Gerrit. I don't know about the latter, but the first is broken.
But If you don't have the first email then threading isn't working. That is the whole point of the problem. You don't have the first email if you are cc'd after the bug is created. I didn't check with recent versions of claws though. Did the behavior change?
(In reply to comment #14) > But If you don't have the first email then threading isn't working. That is > the whole point of the problem. You don't have the first email if you are > cc'd after the bug is created. I didn't check with recent versions of claws > though. Did the behavior change? Exactly that's the point of the this patch. Since there is no first parent email - find the oldest child and pretend it's a parent. It doesn't break or change behavior if you have a real parent.
Paul, what do you think about this improvement? It is an other case that you thought. Main advantage of this patch is that Claws can group loose emails from trackers like Jira, Gerrit and others which send tons of emails. Other email clients handle them well grouping by either In-Reply-To or Subject. Claws can't do this at the moment and it's a disadvantage. It would be great to have this in master branch. I've tested this on my branch and it works great. I can update this patch against current version.
*** Bug 3487 has been marked as a duplicate of this bug. ***