Creating a customised conditional feedback email in Request Tracker when a ticket is resolved

This article assumes that you're running, and familiar with administering Request Tracker. The notes are accurate for 3.8.7, and it may differ for other versions. Hopefully it'll get you a long way to solving it though, and the RT user lists are pretty good -

Something we've wanted to do for a long time is get RT to send an email to requestors based upon the value of custom fields. In our case we want to send an email to the requestor if the following are all true:

  • "Send Feedback" custom field = "Y"
  • "Ticket Type" custom field <> "MAINT" (we use MAINT to track system generated Maintenance tickets)
  • The action occurring on the ticket is to resolve it

Note in our case we don't care if a ticket is re-opened and re-closed. In this case we'll send the email again as long as the above are still true. We also didn't want RT being clogged up with every single ticket including an attachment with the content of the feedback request. We also want to give the operator the ability to determine whether or not to send the feedback request. In some cases this may not be appropriate - in our case we felt it was reasonable to give the operator that leeway for a variety of reasons.

To make this work we needed a few things in place:

These all hang together as follows:

Custom Field: This is used by the scrip to determine whether to send the email or not. It's a simple "Y/N" field.
Scrip: The scrip evaluates the desired conditions. If they are met it sends an email using the global template. If not, then no action is taken.
Template: This contains both code to correctly set the subject of the outgoing email, but also the text content that we wish to send.
SendEmail Extension: This was necessary so that we could override the default RT email subject line, because we wanted a "non-RT-like" email going out.

There were a few gotchas along the way!

1. So, first, install the SendEmail extension following the instructions on the page. It's a simple extension to install and well documented so I won't repeat it here. Making it work was a bit trickier though, but I'll discuss this a bit later.
2. Create your Custom Field(s). I won't go into detail here in how to create a custom field (I will publish a blog entry on how to do this sometime soon, and will link then). Make sure your custom field is enabled and active for the queue in question. Note it's a ticket custom field. Ours is called "RequestFeedback", applies to Tickets, and has two values "Y" and "N". We haven't put a default value in place (not sure how to do this yet).
3. Create a template. This will be used by the scrip in the last step. In our template we wanted to override the default outgoing subject so that it "looked" friendlier. To do this you need to make use of the SendEmail extension referred to above. Our template looks like this (without the horizontal markers ---- obviously):


my $ToAddress = This email address is being protected from spambots. You need JavaScript enabled to view it.';
my $FromAddress = 'My Name ';
my $Subject = $RT::DisableSubjectToken;
$Subject .= 'Feedback on Ticket #' . $Ticket->id;
$OUT = "From: $FromAddress\n";
$OUT .= "Reply-To: $FromAddress\n";
$OUT .= "Subject: $Subject\n\n";


We've resolved your ticket in our system, and we'd like to get feedback from you on your experience so that we can improve how we work and what we do.

To do this please head to this link and complete the 3,455 (quick) questions:{$Ticket->id()}

Your ticket# was {$Ticket->id()} "{$Ticket->Subject()}."

Thank you,

The Boffins


A few comments here:

- I don't know why you need to specify a "$ToAddress" at the beginning. It doesn't appear to be used, but if you don't it breaks.
- the "my $Subject = $RT::DisableSubjectToken;" line is where it does the magic - this turns off the default RT subject (via the SendEmail extension)
- Normally I'd just use the following syntax to specify how I wanted the outgoing email to look - it's far simpler...

Sender: This email address is being protected from spambots. You need JavaScript enabled to view it.
Reply-To: This email address is being protected from spambots. You need JavaScript enabled to view it.
From: My Name
Subject: Feedback on Ticket {$Ticket->id()}

- This doesn't work in this case however because the subject ends up looking like "[ #123345] the original ticket subject Feedback on Ticket 123345" which is just daft. And if you want to remove the initial gumph then you need the block as above.
- Note that the syntax for referring to objects is different between these two ways and indeed within the template proper. In the header you refer to the ticket ID as follows:


Whereas in the body of the template you'll refer to it this way:


I'm sure there's a perfectly good perl reason for this, but this is one of my bug bears. In my opinion it makes customising and troubleshooting RT harder than it should be. This type of problem appears in the RT CLI (Command Line Interface) too, but that's a topic for another day. Other syntax things to be aware of, using the "$Subject .= 'Feedback on Ticket #' . $Ticket->id;" line:
- $Subject # You're setting a variable called Subject, which is then used as the subject of the email
.= # I'm not sure how / why this particular syntax - but you must have a period followed by equals.
'subject text goes here' # plain text enclosed by single quotes.
. # If you want to add something to the subject (like a variable or system object reference) then you use a period with a preceding / trailing space to indicate that you are appending something else to the line. If you don't put the period in, it won't work.
$Ticket->id # Notice that there are no curly braces {} around it, and no parentheses after id() like in the previous example. I don't know why - I just know that if you structure the template using this code then you can't use the trailing parentheses.
; # You have to terminate the line with a semicolon. If you don't it won't work.


4. Last but not least The Scrip!

Lastly, the scrip. This is the bit that tests whether to do something, and if so, do what...

- Create your scrip. We used the following values:
Description: RequestFeedback
Condition: User Defined
Action: Notify Requestors
Template: Global Feedback Template #Remember - the one we just created?
Stage: Transaction Create
Custom Condition:

my $Ticket = $self->TicketObj;

# substitute for the custom field name
my $WantFeedback = $Ticket->FirstCustomFieldValue('RequestFeedback');
my $TicketType = $Ticket->FirstCustomFieldValue('TicketType');

# use whatever status is required
return 0 unless $Ticket->Status eq "resolved";

# substitute for the value you want to act on
return 0 unless $WantFeedback eq 'Y';
return 0 if $TicketType eq 'MAINT';
return 1;


It's a pretty simple piece of code. It populates a couple of variables based upon the custom fields "RequestFeedback" and "TicketType". Note that it does this by the name of the custom field, not the ID. In this case we only want a single value to be returned, so we're looking for "FirstCustomFieldValue".

It then does a few checks. If the ticket is not resolved, it aborts. Similarly if the other desired condtions are not met (WantFeedback=Y and TicketType<>MAINT) it aborts. If these conditions are all satisfied it returns true, which triggers the scrip to perform the configured action (see above), which is to notify requestors (i.e. email them) using the desired template "Feedback template".



Sharing Exchange 2003 folders when the user doesn'...
Making Joomla Update work behind a proxy Update: :...


No comments made yet. Be the first to submit a comment
Mobile Version | Desktop Version