SLA and ticket parking

RT Users
1

Hi,

I’m working on a solution for “parking” tickets with SLA.
Right now I have a custom status AwaitingClientResponse, which is
(I hope) self-explanatory.

The idea is that Owner sets this status and when Requestors answers,
Scrip sets the status back to previous one (or to open, that really
doesn’t matter) and sets the Due date like that:
Due date = Due date + (date now - last status change date)

It all works well, status is being changed, due date is being calculated
and set correctly, and right after that the original SLA Scrip - Set due
date if needed - kicks in and changes due date back to its original
value.

Of course the first thing I tried was to move my Scrip to the end of
Scrip list (both by # number and by name), but still SLA Scrip has the
last word about the due date.

Should I hack the original Scrip?

Best regards,
Robert Wysocki
administrator systemów linuksowych
CONTIUM S.A., http://www.contium.pl

2

Dnia 2012-05-22, wto o godzinie 07:09 +0200, Robert Wysocki pisze:

Hi,

I’m working on a solution for “parking” tickets with SLA.
Right now I have a custom status AwaitingClientResponse, which is
(I hope) self-explanatory.

The idea is that Owner sets this status and when Requestors answers,
Scrip sets the status back to previous one (or to open, that really
doesn’t matter) and sets the Due date like that:
Due date = Due date + (date now - last status change date)

It all works well, status is being changed, due date is being calculated
and set correctly, and right after that the original SLA Scrip - Set due
date if needed - kicks in and changes due date back to its original
value.

Of course the first thing I tried was to move my Scrip to the end of
Scrip list (both by # number and by name), but still SLA Scrip has the
last word about the due date.

Should I hack the original Scrip?

I’ve made some development about it, and I would like to know, if my
approach could be better in some way?

First I’ve added two CF’s: SLA-originalDueDate and SLA-dueExtraTime.
The first one is used to store original DueDate calculated by SLA
extension, the second one - to store extra time that the customer takes
to respond after status has been changed to AwaitingClientResponse.
Those two are set by Scrip whenever there’s a correspondence from one
of the requestors and ticket status is ‘AwaitingClientResponse’.

Next I’ve hacked Action/SLA_SetDue.pm like this:

— SLA_SetDue.pm-original 2012-06-05 08:20:15.000000000 +0200
+++ SLA_SetDue.pm 2012-06-05 08:20:36.000000000 +0200
@@ -49,10 +49,14 @@
Time => $last_reply->CreatedObj->Unix,
);

  • my $time = $ticket->CreatedObj->Unix;
  • my $dueExtraTime = $ticket->FirstCustomFieldValue(‘SLA-DueExtraTime’);
  • $time+=$dueExtraTime;
    my $resolve_due = $self->Due(
    Level => $level,
    Type => ‘Resolve’,
  •    Time => $ticket->CreatedObj->Unix,

  •    Time => $time,

    );

    my $due;

and Condition/SLA_RequireDueSet.pm like this:

— SLA_RequireDueSet.pm-original 2012-06-05 08:29:22.000000000 +0200
+++ SLA_RequireDueSet.pm 2012-05-29 08:36:28.000000000 +0200
@@ -21,7 +21,8 @@
return 0 unless $self->SLAIsApplied;

 my $type = $self->TransactionObj->Type;
  • if ( $type eq ‘Create’ || $type eq ‘Correspond’ ) {
  • if (($type eq ‘Create’ || $type eq ‘Correspond’) and
  •    ($self->TicketObj->Status ne 'AwaitingClientResponse')) {
   return 1 if $self->TicketObj->FirstCustomFieldValue('SLA');
   return 0;
    }

Can I do anything better? Would it be possible to achieve the same
result without those two extra CF’s?

Best regards,
Robert Wysocki
administrator systemów linuksowych
Contium S.A., http://www.contium.pl