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

[Mike Patterson]

Thanks for the suggestion.

In my case I want replies and comments from the web interface to update 
the ticket and I'm willing to live with additional user replies to the 
tech opening a new ticket.

I think this might work, but I need a better understanding of how 
replies and comments go in.  Do replies and comments from the web 
interface use the "comment" action as opposed to correspond action?  If 
so I can copy and modify rt-mailgate and rename it 
"rt-mailgate-InReplyTo" which uses Tony's "ParseInReplyTo" functions for 
rt-comment.

rt-comment: "|/opt/rt2/bin/rt-mailgate-InReplyTo --queue general 
--action comment"
rt: "|/opt/rt2/bin/rt-mailgate --queue general --action correspond"

With this kind of setup I don't have to worry about some of the 
potential bugs: e.g. users trying to create a new ticket by replying to 
an old email with new subject line updating a dead ticket instead of 
creating a new one.

Does it work that way?  If not, how can I make replies and comments from 
  web interface use a different alias?

Thanks,
Mike

Tony Aiuto wrote:
>>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
> 



-- 
-------------------------------
Mike Patterson - UC Berkeley
Computer User Support Group
EECS Computing Helpdesk Manager
-------------------------------