[rt-users] Making RT invisible - changing subject lines

[Tony Aiuto]

>Mike Patterson <map at eecs.berkeley.edu> writes:

>But I'm unclear on how replies sent from the web interface get inserted 
>into the database.  Does it simply do an insert or does it actually 
>email itself and make rt-mailgate insert it?  As far as tech replies 
>sent from the web interface, I definately want them connected to the 
>original ticket.  If it mails itself for an insert I can see that I need 
>the ticket number included in the email (at least for the 
>self-referential copy of the email).

>My MTA is a fairly recent build of sendmail on FreeBSD and anyone can 
>suggest tricks to get it to  insert itself (without modifying the 
>subject line to the user) would be greatly appreciated.

My guess is that rt-mailgate could be beefed up to look at
the 'In-Reply-To' (and maybe Message-ID) headers when it can't
parse the ticket id off the subject line.   Most decent
MUAs should preserve enough info to work

For example
	In-Reply-To: <rt-60 at ICS>
	Message-ID: <rt-60-233.8.7083512469593 at ics.com>

Either of these patterns pretty clearly matches ticket 60.

I tried out the basic concept and it *seems* to work.
Certainly, enhancing rt-mailgate should be mostly harmless.

[The info below is NOT valid patch format.  Do the work by hand]

First, patch lib/RT/Interfaces/Email.pm

*** orig/Email.pm       Fri May  3 01:30:23 2002
--- ./Email.pm  Thu Oct 31 15:25:05 2002
***************
*** 28,33 ****
--- 28,34 ----
                      &CheckForAutoGenerated 
                      &ParseMIMEEntityFromSTDIN
                      &ParseTicketId 
+                     &ParseInReplyTo 
                      &MailError 
                      &ParseCcAddressesFromHead
                      &ParseSenderAddressFromHead 
***************
*** 281,286 ****
--- 283,305 ----
      else {
        return(undef);
      }
  }
  # }}}
+ 
+ # {{{ sub ParseInReplyTo 
+ 
+ sub ParseInReplyTo {
+     my $InReplyTo = shift;
+     my ($Id);
+     
+     if ($InReplyTo =~ s/<support-(\d+)[-@]//i) {
+       $Id = $1;
+       $RT::Logger->debug("Found a ticket ID. It's $Id");
+       return($Id);
+     }
+     else {
+       return(undef);
+     }
+ }
+ # }}}
  


Next patch rt-mailgate

*** rt-mailgate 2002/10/31 20:16:42     1.1
--- rt-mailgate 2002/10/31 20:18:28
***************
*** 24,27 ****
--- 24,28 ----
                             ParseMIMEEntityFromSTDIN
                             ParseTicketId 
+                            ParseInReplyTo
                             MailError 
                             ParseCcAddressesFromHead
***************
*** 116,119 ****
--- 117,121 ----
  my $MessageId = $head->get('Message-Id') || 
    "<no-message-id-".time.rand(2000)."\@.$RT::Organization>";
+ my $InReplyTo = $head->get('In-Reply-To');
  
  #Pull apart the subject line
***************
*** 123,126 ****
--- 125,129 ----
  # Get the ticket ID unless it's already set
  $TicketId = ParseTicketId($Subject) unless ($TicketId);
+ $TicketId = ParseInReplyTo($InReplyTo) unless ($TicketId);
  
  #Set up a queue object


Now, of course, you have to whack at SendEmail.pm so it leaves
off the [$RT::Organization #<ticket>].  I don't have the guts
to try this part out yet.   I'm certainly not going to be the
one to try it on my production system. :-)

There could be many problems.   For example, a customer
who never actually creates a new message when submitting a
ticket, but rather replies to an old, dead ticket and replaces
the subject.   That works in RT as designed, but would break
with the In-Reply-To parsing.

What does Jesse think?


-Tony Aiuto