411601 - Include "Thread-Topic" header on email notifications for Outlook

Status: NEW

(Bugzilla :: Email Notifications, enhancement)

Description

[Jeff Lawson]

Attachment: Add the Thread-Topic header to email notifications

Microsoft Office Outlook uses the email header "Thread-Topic:" to group messages together when in "View->Arrange By->Conversation" display mode.  Adding this header with a value that is invariant for a bug allows all messages associated with that bug to be grouped together, even if the Subject (ie: bug summary) changes.

Comment 1

[Max Kanat-Alexander]

Comment on attachment 296253 [details] [diff] [review]
Add the Thread-Topic header to email notifications

Okay, first off, it pisses me off that Outlook has decided to implement *their* threading feature almost EXACTLY THE SAME as the RFC standard feature, but with a DIFFERENT HEADER NAME? That's so Microsoft.

Sorry, that wasn't directed at you, Jeff. :-) Just a little rant.

Anyhow, we already have a threading marker. See [% threadingmarker %]. It'd be best to re-use that. The trouble with your code will be when people get mail from more than one Bugzilla, I'd imagine.

Comment 2

[Jeff Lawson]

"Thread-Topic:" is not quite identical to "Message-ID/In-Reply-To", since the value it contains is supposed to be human readable and is actually displayed at the top of the grouped sections in Outlook.  The value is typically automatically set by Outlook to be the subject of the first email.

(Outlook does have a corresponding "Thread-Index:" header that contains additional information in a Base64-encoded binary field about the position of message within the thread, but that doesn't seem required for basic grouping functionality.)

I've seen these headers used in Outlook 2000, Outlook 2003, Outlook 2007, but it's probable that it was in use prior to then.

Comment 3

[Jeff Lawson]

A forum message gives some more details about "Thread-Topic" and "Thread-Index":
http://www.officekb.com/Uwe/Forum.aspx/outlook-prog-addins/1934/What-is-ConversationTopic#OBTB812GFHA3912TK2MSFTNGP10phxgbl

Comment 4

[Marc Schumann [:Wurblzap]]

Supporting this would mean we'd need to keep the original summary in our pocket somewhere... I'm not altogether happy with this.

Comment 5

[Jeff Lawson]

There is no need for the Thread-Topic to be the literal bugzilla summary text.  It just needs to be some invariant string that is human-readable (ie: not a cryptographic hash or hex string).

My original recommendation was just "Bug XXX", but Max has a reasonable concern about people who receive bugzilla notifications from different bugzilla installations/projects.

Comment 6

[Marc Schumann [:Wurblzap]]

Well, you could take Bugzilla's urlbase parameter and chop off the http(s):// part at the beginning, I'd say... Being really nitpicky, you'd probably want to keep the whole rest (not just the domain name) so that you can cope with multiple installations on the same server.

Comment 7

[Kent Rogers [:mrbball]]

I recently was introduced to this problem by one of the users at our site.

After some experimentation it looks like the Thread-Topic is not really
applicable.  AFAICT, setting/modifying it does not help keep messages in a
conversation, prevent them from being in a conversation, or even change the
appearance of the conversation.  The Thread-Index header appears to be the
key.

The link in comment 3 is no longer available, but I was able to find this
description of how the Thread-Index is set:

http://msdn.microsoft.com/en-us/library/ee202481%28v=exchg.80%29

This is really an Outlook issue (it *should* be sorting into conversations
using the In-Reply-To & References headers), and I think the only way for
Bugzilla to work around the issue is to duplicate the algorithm Outlook
uses to generate a Thread-Index header for each new bug and save it in the
DB so that a new value can be generated from the previous value (and then
updated in the DB) for each update of the bug.

I understand Max's frustration in comment 1, and I don't know if this is a
fix that the Bugzilla team would consider accepting, but either way, the
summary for this bug should probably be changed to: 'Include a properly
formatted "Thread-Index" header ...'.

If it is something that would be considered, I think Bugzilla would just
need to include a properly formatted Thread-Index header to the threading
marker that is generated in Mailer::build_thread_marker().

Comment 8

[Nathaniel W. Turner]

FWIW, some experimentation suggests that the UUID part of the Thread-Index header value is all that really matters for conversation grouping. Including zero "response level" items in the value appears to be valid (or at least handled gracefully by the MUAs I tested --- Outlook and the "Nine" Android app).

So as a simple workaround to help Outlook with threading, using a fixed timestamp and generating a UUID based on the bug number should be sufficient, and not require any additional state to be stored.

I understand BZ is written in Perl, but by way of example, here's how I tested this:

>>> threaduuid = uuid.uuid4()
>>> base64.standard_b64encode('\x01\x00\x00\x12\x34\x56' + threaduuid.get_bytes())
'AQAAEjRWNURomIn4Rymhw8LVv+HaAA=='

Then fed sendmail a message with "Thread-Index: AQAAEjRWNURomIn4Rymhw8LVv+HaAA==" as one of the headers for several messages. The MUA grouped messages based on the value of threaduuid.