Our RT 2.0.0 hacks

Hi,

We’ve been using RT 2.0.0 live now for about a week and I don’t know
how we managed without it. Thanks to Jesse & Co. for such a great
product :slight_smile:

I’ve made some minor changes to fit it in with our way of working
and our existing systems.

I’ll run through the changes here since they might be
useful/interesting for others. We use RT as an email based trouble
ticketing system for technical support of our software.

  1. Workaround a bug in Mail::Header in lib/RT/Template.pm. This
    workaround is already in place in lib/RT/Action/SendEmail.pm, but we
    had problems with long subject lines generated by
    lib/RT/Template.pm. The fix is:

— ./lib/RT/Template.pm Fri Mar 30 08:32:27 2001
+++ /home/croombs/Template.pm Mon Jul 2 16:53:25 2001
@@ -249,6 +249,9 @@
if ($headers) {
foreach $header (split(/\n/,$headers)) {
(my $key, my $value) = (split(/: /,$header,2));

  •  chomp $key;
    
  •  chomp $value;
    
  •  $self->{'MIMEObj'}->head->fold_length($key,10000);
     $self->{'MIMEObj'}->head->add($key, $value);      
    
    }
    }
  1. When a user attempts to correspond, but does not have permission,
    put the transaction through as a comment. We have a few people who
    correspond with the outside world. This change allows us to add
    people who don’t have ReplyToTicket rights to AdminCC, they can just
    hit reply to comment on email correspondence. Support staff can then
    pass a sanitised version of those comments on to customers if
    necessary :slight_smile: Patch for lib/RT/Ticket.pm

— Ticket.pm.orig Fri Jun 29 15:29:19 2001
+++ Ticket.pm Fri Jun 29 15:31:41 2001
@@ -1582,7 +1582,16 @@

 unless (($self->CurrentUserHasRight('ReplyToTicket')) or
        ($self->CurrentUserHasRight('ModifyTicket'))) {
  •   return (0, "Permission Denied");
    
  •   #       return (0, "Permission Denied");
    
  •   # Tao change KMC 20010629
    
  •   # If the user doesn't have permission to reply to a ticket,
    
  •   # try a comment 
    
  •   my ($result,$msg)= $self->Comment
    
  •           (
    
  •           MIMEObj=>$args{'MIMEObj'},
    
  •           TimeTaken=>$args{'TimeTaken'}
    
  •           );
    
  •   return($result,$msg);
    

    }

    unless ($args{‘MIMEObj’}) {

  1. New scrip action “BounceAll”. We wanted email attachments on
    correspondence to be passed on. BounceAll.pm also removes people
    from To, Cc & Bcc if they were on the To or Cc list of the original
    email. We have $ParseNewMessageForTicketCcs set, which causes email
    Cc’s to be added to RT’s Cc list. When RT sends email out it is
    CC’d to those on the CC list. If the requester happens to
    "reply-to-all", they’ll send a mail to RT and RT’s CC list - when RT
    gets the mail it’ll send yet another copy to everyone on the CC
    list. BounceAll removes these people so that they only get one
    copy. Attached “BounceAll.pm”.

  2. New scrip action “Reopen”. This just reopens tickets. I wanted
    comments to reopen issues. We use bugzilla to track bugs, and we
    link bugs to RT tickets by adding the RT ticket identifier to the
    bug summary, and adding the rt-comment address to the bug’s CC list.
    Thus when a bug’s state changes (i.e. a bug is fixed), the comment
    will unstall a stalled ticket, reminding us to inform the requester
    that the problem has been fixed. I’m thinking of changing this
    action to “unstall” rather than reopen. I don’t want to reopen
    tickets that have been “resolved”, because then we’ll have to
    re-resolve them and the requesters will get multiple “Request
    Resolved” emails. Attached “Reopen.pm”.

Our scrips are as follows:

OnResolve NotifyRequestorsAndCcs with template Resolved
OnComment NotifyAdminCcsAsComment with template AdminComment
OnComment Reopen with template Autoreply
OnCreate AutoreplyToRequestors with template Autoreply
OnCreate BounceAdminWatchers with template Correspondence
OnCorrespond BounceAllWatchers with template Correspondence

You’ll need to update your ScripActions table if you want to use
these modules, something like:

insert into ScripActions(Name, Description, ExecModule, Argument)
values (“BounceAllWatchers”, “Forward mail to all watchers”,
“BounceAll”, “All”);

insert into ScripActions(Name, Description, ExecModule, Argument)
values (“BounceRequestorsAndCcs”, “Forward mail to requestors”,
“BounceAll”, “Requestor,Cc”);

insert into ScripActions(Name, Description, ExecModule, Argument)
values (“BounceAdminWatchers”, “Forward mail to admin watchers”,
“BounceAll”, “AdminCc”);

  1. Don’t display attachments inline if their headers say
    "Content-Disposition: Attachment". Might be personal preference,
    but I didn’t want to inline text that doesn’t want to be inlined.
    Attached “ShowTransaction.patch” & “ShowTransaction1.patch”.

  2. I pass email through the following procmail recipes before
    sending it to RT. This turns non-MIME attachments into MIME
    attachments:

:0 fw

  • ^Content-Type: x-sun
    | emil -G mime8_user

:0

  • Content-Type: text
    {
    :0 fBw
    * ^begin [0-7][0-7[0-7]
    * ^end
    | formail -i Mime-Version | emil -G mime8_user
    }
    :0
  • !Content-Type:
    {
    :0 fBw
    * ^begin [0-7][0-7][0-7]
    * ^end
    | emil -G mime8_user
    }

:0

  • ^Content-Type: multipart/mixed
    {
    :0 fBw
    * ^Content-Type: application/mac-binhex
    | emil -G mime8_user
    }

Other bits that I’m thinking of looking into:

  • When the web UI is used to comment/correspond, the resulting email
    that is sent out appears as one very long line when viewed in MS
    Outlook. I have fixed a similar problem with bugzilla in the past,
    I’ll see if I can track it down in RT. I think that it’s a problem
    with Outlook, but we have Outlook users.

  • We have some customers that have configured their mailers not to
    insert line breaks at the end of lines (i.e. no word wrap). When
    these mails are viewed from the RT web pages, the lines do not wrap

  • you need to scroll along horizontally to read the email. Again,
    strictly speaking this probably isn’t an RT problem, but we can’t
    tell our customers how to configure their mailers :slight_smile:

  • It would be great to have a system whereby users can specify
    patterns for email headers/bodies that when matched would cause the
    user to be automatically added to the AdminCC list. This could be
    used by people who want notification whenever company X has a
    problem, or by developers who want to know whenever there’s a
    problem with module Y.

Comments/suggestions welcome. I am aware that my perl is horrid :slight_smile:

Kevin Croombs - Technical Support
Tao Group (http://www.tao-group.com)

ShowTransaction.patch (572 Bytes)

ShowTransaction1.patch (642 Bytes)

Reopen.pm (1.04 KB)

BounceAll.pm (2.68 KB)

Hello again,

[…]

  • When the web UI is used to comment/correspond, the resulting email
    that is sent out appears as one very long line when viewed in MS
    Outlook. I have fixed a similar problem with bugzilla in the past,
    I’ll see if I can track it down in RT. I think that it’s a problem
    with Outlook, but we have Outlook users.

lib/RT/Interface/Web.pm appears to be doing the right thing, so I’m
not sure why this is happening.

line 121:
#Make the update content have no ‘weird’ newlines in it
if ($args{ARGSRef}->{‘UpdateContent’}) {
my @UpdateContent = split(/(\r\n|\n|\r)/,

Kevin Croombs - Technical Support
Tao Group (http://www.tao-group.com)

Thanks very much for your changes and fixes :slight_smile:
If you’re willing to do up the bigger ones (like the scrips and procmail
recipes) as seperate files with their own readmes, I’d love to drop
them in /contrib.

  1. Workaround a bug in Mail::Header in lib/RT/Template.pm. This
    workaround is already in place in lib/RT/Action/SendEmail.pm, but we
    had problems with long subject lines generated by
    lib/RT/Template.pm. The fix is:

Something like this will be in 2.0.1

  1. When a user attempts to correspond, but does not have permission,
    put the transaction through as a comment. We have a few people who
    correspond with the outside world. This change allows us to add
    people who don’t have ReplyToTicket rights to AdminCC, they can just
    hit reply to comment on email correspondence. Support staff can then
    pass a sanitised version of those comments on to customers if
    necessary :slight_smile: Patch for lib/RT/Ticket.pm

You might want to look at moving this change into the mail gateway,
rather than the core.

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

“Bother,” said Pooh, “Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three”