Making RT 3.8.1 grok References: and In-Reply-To:

RT Users
1

I don’t know if this is of general interest or not…

I found the patches at http://www.usit.uio.no/it/rt/modifications/
that allow RT to associate email with tickets based on the References:
and In-Reply-To: headers if there is no subject tag. I’ve made these
work with RT 3.8.1; the changes are here:

Google Code Archive - Long-term storage for Google Code Project Hosting.

These are only briefly tested and are not in production use, but I
figured someone else might be interested.

– Lars

Lars Kellogg-Stedman lars@oddbit.com

2

I don’t know if this is of general interest or not…

I found the patches at http://www.usit.uio.no/it/rt/modifications/
that allow RT to associate email with tickets based on the References:
and In-Reply-To: headers if there is no subject tag. I’ve made these
work with RT 3.8.1; the changes are here:

It’s something I’m of two minds about. On the one-hand, it’s a really
slick feature that makes a lot of things easier. On the other hand, it’s
quite common for users to open new tickets by popping up an old ticket
reply and changing the subject and body. Which will incorrectly thread
it as on the previous ticket. (Most mail clients don’t expose
“in-reply-to” and “references” headers for user editing.)

It’d be cool if this could become an RT extension that oculd be cpanned.

3

This reply missed the list the first time around:

It’s something I’m of two minds about. On the one-hand, it’s a really
slick feature that makes a lot of things easier. On the other hand, it’s
quite common for users to open new tickets by popping up an old ticket
reply and changing the subject and body. Which will incorrectly thread
it as on the previous ticket. (Most mail clients don’t expose
“in-reply-to” and “references” headers for user editing.)

This all came about from a “hey, ticket system product A has this
feature that seems really slick, why doesn’t RT do that”? So it was
more proof of concept than anything else. The fact that RT, at least
in 3.8.1, is already collecting message ids made my life much easier.
One could perhaps implement some sort of time threshold to help winnow
out this sort of thing. I don’t know how other ticket systems that
use the references information as a primary source handle this.

It’d be cool if this could become an RT extension that could be cpanned.

If I’m the only person using this code (and only in my personal RT at
the moment, not in our production system), this probably won’t
percolate very high up on my to do list. If someone else wants to try
it out and verify that it works as described and spot any problems,
I’d be happy to take a look at it.

The biggest problem I see with making this an installable extension is
that it requires patching RT/Interface/Email.pm. It’s a one-liner…

— Email.pm.orig 2008-10-28 13:58:18.979900000 -0400
+++ Email.pm 2008-10-28 13:58:29.726978000 -0400
@@ -1229,6 +1229,7 @@
}

$args{'ticket'} ||= ParseTicketId( $Subject );
  • $args{‘ticket’} ||= ParseReferences( $head );
$SystemTicket = RT::Ticket->new( $RT::SystemUser );
$SystemTicket->Load( $args{'ticket'} ) if ( $args{'ticket'} ) ;

…but I’m not sure where else to put it. To make this more graceful,
there would need to be a registry of some sort so that the above code
would look something like:

for my $func (@registered_functions) {
$args{‘ticket’} = &$func($head) && last;
}

Or something. Maybe the MailPlugins interface could be beefed up to
do more than authentication work? If this could add arbitrary
attributes to the message object ($message->add(‘rt-ticket-id’, …)),
that would be a fine place to insert this sort of code. Then Email.pm
wouldn’t explicitly do subject line scanning; this would be in a
MailPlugin that was enabled by default…or enabled unilaterally, or
something.

5

This reply missed the list the first time around:

It’s something I’m of two minds about. On the one-hand, it’s a really
slick feature that makes a lot of things easier. On the other hand, it’s
quite common for users to open new tickets by popping up an old ticket
reply and changing the subject and body. Which will incorrectly thread
it as on the previous ticket. (Most mail clients don’t expose
“in-reply-to” and “references” headers for user editing.)

This all came about from a “hey, ticket system product A has this
feature that seems really slick, why doesn’t RT do that”? So it was
more proof of concept than anything else. The fact that RT, at least
in 3.8.1, is already collecting message ids made my life much easier.
One could perhaps implement some sort of time threshold to help winnow
out this sort of thing. I don’t know how other ticket systems that
use the references information as a primary source handle this.

It’d be cool if this could become an RT extension that could be cpanned.

If I’m the only person using this code (and only in my personal RT at
the moment, not in our production system), this probably won’t
percolate very high up on my to do list. If someone else wants to try
it out and verify that it works as described and spot any problems,
I’d be happy to take a look at it.

The biggest problem I see with making this an installable extension is
that it requires patching RT/Interface/Email.pm. It’s a one-liner…
Actually this’s a wrong API change I missed during RT 3.6.x, earlier
we were passing more than $Subject into ParseTicketId function.

I think it’s possible to pass MIMEObj next to $Subject into
ParseTicketId function and override it in extension or wrap. I’m happy
to apply such change for 3.8.2.

— Email.pm.orig 2008-10-28 13:58:18.979900000 -0400
+++ Email.pm 2008-10-28 13:58:29.726978000 -0400
@@ -1229,6 +1229,7 @@
}

$args{‘ticket’} ||= ParseTicketId( $Subject );

  • $args{‘ticket’} ||= ParseReferences( $head );

$SystemTicket = RT::Ticket->new( $RT::SystemUser );
$SystemTicket->Load( $args{‘ticket’} ) if ( $args{‘ticket’} ) ;

…but I’m not sure where else to put it. To make this more graceful,
there would need to be a registry of some sort so that the above code
would look something like:

for my $func (@registered_functions) {
$args{‘ticket’} = &$func($head) && last;
}

Or something. Maybe the MailPlugins interface could be beefed up to
do more than authentication work? If this could add arbitrary
attributes to the message object ($message->add(‘rt-ticket-id’, …)),
that would be a fine place to insert this sort of code. Then Email.pm
wouldn’t explicitly do subject line scanning; this would be in a
MailPlugin that was enabled by default…or enabled unilaterally, or
something.

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

6

Or something. Maybe the MailPlugins interface could be beefed up to
do more than authentication work? If this could add arbitrary
attributes to the message object ($message->add(‘rt-ticket-id’, …)),
that would be a fine place to insert this sort of code. Then Email.pm
wouldn’t explicitly do subject line scanning; this would be in a
MailPlugin that was enabled by default…or enabled unilaterally, or
something.

Have a look at the CommandByMail plugin. it can do message rewriting.
That might give you the rope yuou need.

7

You can have _Local versions of core modules in extensions.

I see that you have not actually looked at my code :). In addition to
the one-line patch to RT/Interface/Email.pm, the bundle includes
RT/Ticket_Local.pm and RT/Interface/Email_Local.pm.

For
something like this, you probably want to try to implement your tweak
as a wrapper around the existing code. See RTx::Tags’ Search library.

The code in question is big and ugly. I could replace it, but I’m
not sure that I can wrap or extend it. If you’d care to suggest a
specific change I would appreciate the inspiration.

Lars Kellogg-Stedman lars@oddbit.com

8

I think it’s possible to pass MIMEObj next to $Subject into
ParseTicketId function and override it in extension or wrap. I’m happy
to apply such change for 3.8.2.

If ParseTicketId() had access to all of the message headers, this
would indeed make it easier to affect this change. Might even be
useful for other things. I’m all for it.

Lars Kellogg-Stedman lars@oddbit.com

10

I think it’s possible to pass MIMEObj next to $Subject into
ParseTicketId function and override it in extension or wrap. I’m happy
to apply such change for 3.8.2.

From an RT::Interface::email::Plugin, you have $args{‘Message’}, which
is the MIME::Entity RT will be working with.

You can replace the MIME::Entity’s subject with one containing a ticket
id you want to thread it into.

Ignore the badly named method GetCurrentUser. Side effects inside are a
standard way to massage messages before ticket update/create.

11

I see that you have not actually looked at my code :).
Nope. Not necessary to answer you question about patching core.

Oh look, it’s the internet.

– Lars

Lars Kellogg-Stedman lars@oddbit.com

12

You can replace the MIME::Entity’s subject with one containing a ticket
id you want to thread it into.

I’d actually considered that, but one of the uses cases I was looking
at would be a “stealth” RT – for example, in addition to our
organizational RT, I run one of my own for tracking personal email.
At the moment, that means people get subject tags that they may wonder
about. Ideally, I’d like my use of a ticket system to be more subtle.

I’ll take a closer look at the plugin options, though, and see if I
can come up with something else. While the delivery was a little
rough, Jerrad’s suggestions point to another possible solution,
although it’s a little hacky for my taste.

Lars Kellogg-Stedman lars@oddbit.com

13

You can replace the MIME::Entity’s subject with one containing a ticket
id you want to thread it into.

I’d actually considered that, but one of the uses cases I was looking
at would be a “stealth” RT – for example, in addition to our
organizational RT, I run one of my own for tracking personal email.
At the moment, that means people get subject tags that they may wonder
about. Ideally, I’d like my use of a ticket system to be more subtle.

nod If you can make that go, I’d love to see it. It’s something I’ve
wanted for a long time but not had the cycles to devote to it.

14

[Hmm, replying to a rather stale thread, never mind…]

Someone asked on Mastodon about ticketing systems that’d use References headers to create a new ticket and link to other existing tickets. The use case being I expect is “hit reply, clear subject line to make new ticket, but record relationship”.

That seems to like the best of both worlds, as using ticket merging, you could trivially merge the tickets if the new ticket is really to do with the old ticket.

Cheers,
Andrew