Grab whole correspondence/comments on ticket into one mbox-formatted file

We have begun actively using RT to track most everything that the
employees do here at FSF, and everyone is quite happy with it. (Thanks to
Jesse and Best Practical for their assistance in getting it running and
developing great new Debian packages for RT.)

One feature that I would like is the ability to quickly grab the entire
correspondence and comments on a given ticket into one, single mbox file
that I could then use with an MUA to browse.

It seems that scripting such a thing should be quite easy, but before I
hacked it up, I wanted to check to see if such a script already existed
before I go off writing it.

Thanks for your time.

– bkuhn

[…]

One feature that I would like is the ability to quickly grab the entire
correspondence and comments on a given ticket into one, single mbox file
that I could then use with an MUA to browse.

It seems that scripting such a thing should be quite easy, but before I
hacked it up, I wanted to check to see if such a script already existed
before I go off writing it.

We AdminCC our support queue to a mailbox for safety reasons (then if RT
goes down for whatever reason we have a record we can quickly get to).

If you did this, and altered the Comment AdminCC template to not put
[Comment] in the subject line, then you could see the entire ticket as a
single thread in mutt (or your favourite MUA). Then it’d be trivial to
tag that and pull it into another mailbox (or you could just read the
mailbox in there).

I’m not aware of a script to do it, but that might be quicker.

HTH!

Robie Basak,
Northern Principle Limited

We AdminCC our support queue to a mailbox for safety reasons (then if RT
goes down for whatever reason we have a record we can quickly get to).

This is a possibility; I’ll consider that. OTOH, hacking up a script to
work as I described would probably be a good opportunity to get used to
RT’s APIs. :wink:

If you did this, and altered the Comment AdminCC template to not put
[Comment] in the subject line, then you could see the entire ticket as a
single thread in mutt (or your favourite MUA).

Actually, I have a procmail hack that makes sure a whole ticket always
gets threaded together, no matter what the subject line. Here it is,
FWIW:

:0 fw

  • !^References:
  • ^In-Reply-To: <rt-[0-9]>
    | formail -R “In-Reply-To:” “References:”

What I noticed is that RT seems to be good about always adding an
In-Reply-To: header, but doesn’t add a References: header. For some
reason, mutt doesn’t use In-Reply-To:'s to form threads (it seems like it
should, but it doesn’t).

I wonder, is there a specific reason that RT doesn’t add a References:
header as well as an In-Reply-To:?

– bkuhn

Bradley M. Kuhn:

It seems that scripting such a thing should be quite easy, but before I
hacked it up, I wanted to check to see if such a script already existed
before I go off writing it.

I’m not aware of one, but yeah, it should be pretty easy to hack up; if I were
you, though, I’d do it not as a standalone script, but as an option to
Ticket/Display.html or similar, so that you can then add a button to the
ticket’s page to download the mbox. This also has the advantage that the
work of getting the ticket loaded up and so on is already done for you; you
just need to iterate through the Transactions.

Simon

“In space ‘cat scream.au | tee /dev/null > /dev/audio’…”

  • Ben, in the monastery.

Bradley M. Kuhn wrote:

What I noticed is that RT seems to be good about always adding an
In-Reply-To: header, but doesn’t add a References: header. For some
reason, mutt doesn’t use In-Reply-To:'s to form threads (it seems like it
should, but it doesn’t).

I wonder, is there a specific reason that RT doesn’t add a References:
header as well as an In-Reply-To:?

lib/RT/Action/SendEmail.pm states:

TODO We should always add References headers for all message-ids

of previous messages related to this ticket.

so I guess the reason is “haven’t gotten around to it yet”. :slight_smile:

The solution would be to iterate through $self->TicketObj->Transactions
tacking any found Message-IDs onto the References header; possibly
limiting the size of said header along the way. (I’d go for first three
plus last three or some such.)
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances