This issue is a copy of messages from the mailing 
list.

Logged In: YES 
user_id=6405

Date: 10 Dec 2001 18:04:15 +0100
From: Patrick Ohly

The biggest change is the support for message threading 
with In-Reply-To in the message headers. There are three 
situations here: a reply by email to an existing issue 
where we have a In-Reply-To which is dropped by roundup 
when storing this reply in its database and then bouncing 
it to the nosy list; an issue is modified by web; creating 
a new issue via email and bouncing it back to the author.

What I did is adding a "inreplyto" property to my issue 
and msg classes. If the mail gateway adds a msg node, it 
sets its inreplyto to the same value that the incoming 
email had, and the roundupdb code adds it again when it 
sends this msg. This solves the first case and allows deep 
nesting just as in normal email discussions. Using the 
message id if it is a new issue solves the last case.

The roundupdb also treats the very first msg for an issue 
in a special way: it creates the Message-Id itself (from 
the roundup email address and the designator), and stores 
this id in the inreplyto property of the issue. This id is 
used for all msgs which don't have their own inreplyto, 
e.g. for those created via web. That way one can have at 
least a "flat" thread which is anchored in the first msg 
for this issue.

There are a few issues with these patches: roundupdb 
should still work if the inreplyto property is not present 
in the database scheme, but catching KeyError is perhaps 
not the best solution to do that. I know that mailgw 
breaks when trying to set the inreplyto property if it 
isn't there - I don't really know how to do it better in 
the self.db.msg.create() call. I also don't know how to 
store None as property value - should the property be 
omitted? mailgw currently stores empty strings instead, 
which isn't quite the same.

Logged In: YES 
user_id=6405

Hrm - the mechanism is a nice idea - but requires that the 
message-id also be stored on each node. You can't support 
threading in the web interface without it. And having 
threading in the web interface would be pretty doovy - as 
I think about it, it's actually one of the problems I have 
with most bug trackers - the inability to directly comment 
on something someone said much earlier in the life of an 
issue. Threading would help that a lot. Do you feel up to 
producing a new patch with messageid generation for web 
messages?

Logged In: YES 
user_id=6405

implemented