[rt-users] Importing mbox into RT3...

[Daniel Freedman]

Hi,

I'm currently using the typical beginning method of doing
issue-tracking---my personal mailbox (in my case, Mutt as MUA)---and
very much looking to upgrade to rt3.  I've installed the official
debian testing package implementing rt3.0.12, and everything works
very smoothly.

However, I'd really like to migrate all the existing "tickets" into
rt3, so that it accurately captures all the information and history of
previous interactions.  I looked for an 'mbox2rt3' type of script, but
couldn't find any mention of it.  At first, though, it appears doable
enough, where I can just 'bounce' (to preserve the headers) all the
emails to the appropriate addresses (corresponding to queues) for the
rt3 setup and then they are all in the rt3 system, with the correct
sender and everything.  A few problems with this, though:

1. RT3, by default, will then send very confusing (in this case)
emails to all creators of tickets, dealing with issues that were
solved many months ago.  This is actually an easy fix: we can go into
'Global' / 'Scrips' and disable the 'On create' and 'On resolve'
(etc.) scrips that typically interact with the requestor.  Then, once
everything is imported, reenable them. Okay, that's solved.

2. The creation dates of all the imported messages are wrong, since
they reflect the present time (of the bounce), rather than the initial
time of the message.... Hmm.   One could imagine somehow fixing this
at the db level, but it doesn't seem so easy.  Could really use some
advice and guidance on this one, but I guess if we have to live with
wrong dates, then we will.

3. The hardest, it appears, is the proper chaining / threading of the
email messages.  Clearly, when I bounce each email into rt3, it will
by default create a new ticket for it.  We can go to the relationship
characteristics of the initial ticket and proceed to merge all
continuing communication between requestor and "owner" into the
initial ticket.  However, this doesn't really do exactly what we'd
like, since the "owner" is then added as an additional requestor.
Well, we can then manually delete that addition to recover the
original requestor.  Not pretty, but doable.  However, the linkage is
still a little sloppy since RT3 doesn't show the chain of emails as
the typical request / correspondence of a "real" RT3 workflow, but
instead still shows each as a separately created ticket (in the
metadata of the information flow), that are just merged together onto
the first ticket.  This isn't too pretty either...

Anyone have better ideas?  I searched around the Wiki and docs and
mailing list but couldn't find much, and I can't imagine noone else
has wanted to do the same.

Thanks,
Daniel


-- 
Daniel A. Freedman <freedman at physics.cornell.edu>, Graduate Fellow
  Electronic Structure Calculations, LASSP, Cornell University