[rt-devel] Our RT 2.0.0 hacks
Kevin Croombs
kevin_croombs at tao-group.com
Fri Jul 6 09:10:32 EDT 2001
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 :)
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);
}
}
2. 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 :) 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'}) {
3. 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".
4. 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");
5. 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".
6. 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 :)
- 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 :)
--
Kevin Croombs - Technical Support
Tao Group (http://www.tao-group.com)
-------------- next part --------------
--- ./WebRT/html/SelfService/Elements/ShowTransaction.old Thu Jun 28 12:21:58 2001
+++ ./WebRT/html/SelfService/Elements/ShowTransaction Fri Jun 29 15:23:45 2001
@@ -37,7 +37,7 @@
</TR>
</TABLE>
-% if ($message->ContentType =~ m{^(text/plain|message)} && length($message->Content)<13456) {
+% if ($message->ContentType =~ m{^(text/plain|message)} && length($message->Content)<13456 && $message->Headers !~ m{^content-disposition:\s*attachment}im) {
<pre>
%#TODO We're now HTML escaping the message content, but should
%#TODO probably deal with converting links
-------------- next part --------------
--- ./WebRT/html/Ticket/Elements/ShowTransaction.old Mon Jun 18 20:39:53 2001
+++ ./WebRT/html/Ticket/Elements/ShowTransaction Fri Jun 29 15:24:09 2001
@@ -36,7 +36,7 @@
</TR>
</TABLE>
% # 13456 is a random # of about the biggest size we'd want to see inline text
-% if ($message->ContentType =~ m{^(text/plain|message)}i && length($message->Content)<13456) {
+% if ($message->ContentType =~ m{^(text/plain|message)}i && length($message->Content)<13456 && $message->Headers !~ m{^content-disposition:\s*attachment}im) {
<pre>
%#TODO We're now HTML escaping the message content, but should
%#TODO probably deal with converting links
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Reopen.pm
Type: application/x-perl
Size: 1066 bytes
Desc: not available
Url : http://pallas.eruditorum.org/pipermail/rt-devel/attachments/20010706/916575bd/Reopen.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BounceAll.pm
Type: application/x-perl
Size: 2748 bytes
Desc: not available
Url : http://pallas.eruditorum.org/pipermail/rt-devel/attachments/20010706/916575bd/BounceAll.bin
More information about the Rt-devel
mailing list