User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: Often I file away threads for reference later, but in many cases the more interesting parts of the discussion no longer really fall under the category of the subject of the original message. So, the idea here is to be able to create a "Thread Subject" that is not associated with any particular message in the thread, directly, but with the thread itself (this might be difficult, but somehow it would use the message-ids and in-reply-to headers. I can think of an implementation that may or may not work, but I'll save that for later). This will manifest itself in several ways: In the multi-message view, for a thread, you are able to modify the multi-message heading. From that point on, the custom heading is displayed instead of the first message's subject in several places 1. in the multi-message view in the message pane 2. in the message list, for the threaded view, the top level node becomes the custom thread subject (having it selected shows the multi-message view in the message pane), and the rest of the messages in the thread is reparented underneath that new special "subject node". (If you're not using the threaded view, there there is no change here). 3. as a "fake" header in the header section of the individual messages in the thread in the message pane. I'm a little less enthusiastic about 3 since it basically seems to be adding a header to the message, even though that is not the case. The reason I don't feel bad about flat-out replacing the subjects with the custom subject in spots 1 and 2 above is that this is essentially an opt-in feature, so it shouldn't bother anyone who doesn't use it. Now for my own ignorant implementation (take it or leave it): 1. when a custom thread subject is created, that thread gets a guid (i'll call it a thread-id) that is stored in the sqlite database 2. all the messages currently in that thread are associated with the thread-id 3. when a new message arrives, using whatever the current threading algorithm is, you basically check to see if it's referenced or in-reply-to messages are already associated with a thread-id, and if so, you associate the new message with that same thread-id. That's it! I will try and make some mock-ups that describe the idea.. Reproducible: Always

This shows the edit functionality in the multi-message view, along with how it would appear in the message list. It does not show the fake header for a single message that is part of the thread.

How is this different than bug 91106 ?

I think there are two main differences. First, this is focused on threads, not individual messages, and is more in the vein of assigning a free-form text label to an entire thread. Second, this doesn't affect individual messages in any way and is purely a local change. (I'm not sure I even like the idea of actually changing the subject of an individual message since for some reason I feel like a sent message should be sacrosanct). Part of the motivation for this request is that over the course of a long thread the theme usually varies from the subject of the original mail, and really, what I would like to do is assign a title representing that theme to the entire thread, so that I can search for it by that theme/title later, and find the whole thread in the results. To be honest, if this is a wanted feature I would be willing to implement it myself (I'd just need some guidance since I'm not familiar with the TB source). I just want to gauge whether or not it's a desired feature and that there is no technical reason not to implement it.

(In reply to comment #3) > To be honest, if this is a wanted feature I would be willing to implement it > myself (I'd just need some guidance since I'm not familiar with the TB source). > I just want to gauge whether or not it's a desired feature and that there is no > technical reason not to implement it. Bryan can you give your thoughts on this ? Standard8/Bienvenu what would be good pointers to start implementing that ?

There's no real simple answer to this. Ideally, you'd just add an attribute to the gloda conversation object, and convince gloda to add that attribute to the full text search. That's the forward-looking solution, and Andrew could tell you better than I how to accomplish that. At the moment, gloda doesn't guarantee that it won't delete the global db and regenerate it from information stored in the .msf files and the message itself, but at some point that has to change. It would also be possible to store an override subject on a message as a new property of the msg hdr, in the .msf file, e.g., msgHdr.setStringProperty("OverrideSubject", "some new subject string"); and also call msgHdr.subject = "some new subject string". The tricky part is that you need the override to survive rebuilding the .msf file (e.g., the user clicks the rebuild index button on the property dialog). The code in nsParseMailMessageState::FinalizeHeaders would need to know about overridden attributes and maintain the override. All of this ignores the imap question of how to make this work for imap. IMAP has no concept of a conversation, so the only way to have conversation attributes stored on the imap server is to store them on every message in the thread as keywords, or to have some out of band syncing mechanism like Weave, or use a hidden imap folder with out of band info stored in messages.

I would suggest something along the lines of what bienvenu said. Implement an extension that sets properties on the nsIMsgHdrs of the messages affected. Implement a gloda message attribute provider plugin that uses the header when present and changes the conversation structuring as appropriate. The gloda plugin could re-clobber the subject property on the nsIMsgHdr as required during reindexing. I don't think such functionality would be appropriate for the core of Thunderbird anytime soon.

In terms of UI I would just use the extension to add some kind of pen/edit icon to the subject in the message header and the thread summary view. Then maybe open up a panel type popup (like the star address popup) for editing the subject. It will take some time to refine the designs of the interactions and look so the functionality is obvious and easy to use; start simple and we can build up from there.