[rt-users] Getting relative time in a template, configuring SLA and SLA alerting [SOLVED]

Craig Ringer craig at 2ndquadrant.com
Mon Feb 18 23:37:42 EST 2013

Hi all

I found it surprisingly hard to convert ticket dates like Ticket->Due
into relative friendly dates and times in templates as part of my work
on proper SLA monitoring and alerting in RT. Having found the answer, I
though I'd post it here for anyone else searching for information on the

What I did is add a block to the very start of my alert email template
that defines a package variable, say $tdiff, with the time difference.
The time difference is obtained by constructing an RT::Date with the
system user, setting the date, and using RT::Date::AgeAsString() . (For
some reason RT::Date::DiffAsString always produced an undef result). The
variable can then be referenced anywhere else in the template with {our
$tdiff;} . Tickets are defined as storing the Due date in ISO format in
GMT, so those parameters should be specified to RT::Date.


  my $d = RT::Date->new(RT::SystemUser);
  $d->Set(Format=>'ISO', Value=>$Ticket->Due, Timezone=>"GMT");
  our $tdiff = $d->AgeAsString();
}Subject: SLA Warning: Due in {our $tdiff}

Action is required on this ticket within {our $tdiff} in order to remain
within SLA service levels.

Since RT::Date::AgeAsString() appends "ago" automatically for negative
dates, it's also reasonable to write something like:

Subject: SLA Failure: Due ${our $tdiff}, critical action required

I've added this here:


... but it strikes me that this should really be a helper function in
RT::Date so you don't have to create and set and instance just to call
one method and discard it. OTOH, perhaps my Perl-ignorance is biting me,
and there is a simple and easy way to do it.

Note that the template doesn't do anything by its self. To actually get
SLA alerting working, I landed up:

* Installing RT::Extension::SLA, including the DB setup step to add the CF
* Configuring RT::Extension:SLA as per the docs to describe my SLAs and
the working hours of the various teams.
* Reloading RT to get the SLA module activated
* Following the rt-crontool docs to create a local user for scheduled
* Defining the following job as /etc/cron.d/requesttracker4-sla:

*/5 * *   *   *   requesttracker4   rt-crontool --search
RT::Search::FromSQL --search-arg "(Status='new' OR Status='open') AND
FinalPriority > 0 AND Due >  'Jan 1, 1970'"  --action

to, every five minutes, run RT::Action::EscalatePriority on open tickets
with due dates and final priorities set. The connection to
RT::Extension::SLA here is that RT::Extension::SLA auto-sets the due
date based on the SLA when the ticket is created or changed. This
crontool job isn't actually running any SLA code directly, but it's
using information provided by SLA.

I also want email SLA warnings to go out. This is what the template
described at the start of this mail is for. I create that template as
(say) "SLA Due" in the global templates. Then I add another cron job
that runs something like this:

*/5 * *   *   *   requesttracker4   rt-crontool --verbose  --transaction
last --search RT::Search::FromSQL --search-arg "Due < '30 minutes'"
--action RT::Action::RecordComment --template 'SLA Due'

Again, you don't see any SLA specific code run here because it's using
the Due time set by the SLA module whenever the ticket changes. This
command will add a private (assuming your permissions are set
appropriately) comment on the ticket, the creation of which will trigger
the generation of email notifications as if the comment had been added
manually in the web ui. A comment will not be treated as satisfying a
Response SLA so the creation of the comment won't resolve the SLA issue
by its self.

You need to be careful to make sure that the client accounts and the
requestor pseudo group don't have rights to read comments, or you'll be
sending these SLA warnings to the client too.

The same approach can be used with a custom Action command to send
SMSes. I'm adapting my RedOxygen SMS gateway script to be callable from
an RT action right now, and will follow up with it when it's ready so
nobody else has to waste their time implementing the same thing.

There's more you're likely to want, including a dashboard entry showing
tickets in SLA priority order with severity highlighting, a summary
report of time left before resolution of all tickets across a time
period, etc. I haven't done those yet so I can't help there, but will
try to follow up when I have.

Next problem: How to bind multiple accounts (addresses) together into
"customers" who can all see each others' tickets. It's amazing that this
doesn't seem to be built-in to RT. Ideas? I'll follow up with solutions,
either mine or others'.

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20130219/94a502fc/attachment.htm>

More information about the rt-users mailing list