RT::Extension::SLA -- problems

RT Users
1

Hi all,

I am having a problem with the SLA module.

Any time we change a due date, The SLA module changes it back to the
prescribed due date in the config file.

Is there any way to change this behavior?

RT Version: 3.8.4

Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

2

Nope, cuz SLA extension is used to automate due date management. What
are you trying to achive? How is extension is configured? I want to
know more about use case to understand if it’s possible to improve
this extension.On Mon, Jul 6, 2009 at 9:12 PM, William Graboyeswilliam.graboyes@theportalgrp.com wrote:

Hi all,

I am having a problem with the SLA module.

Any time we change a due date, The SLA module changes it back to the
prescribed due date in the config file.

Is there any way to change this behavior?

RT Version: 3.8.4

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

3

Hi Ruslan,

What are you trying to achive?

We have some SLA Categories that the due dates are “as mutually agreed upon”
Thus they are sending a due date along with the ticket.

How is extension is configured?Set( %ServiceBusinessHours, (
‘Default’ => {
0 => {
Name => ‘Sunday’,
Start => undef,
End => undef
},
1 => {
Name => ‘Monday’,
Start => ‘08:00’,
End => ‘17:30’
},
2 => {
Name => ‘Tuesday’,
Start => ‘08:00’,
End => ‘17:30’
},
3 => {
Name => ‘Wednesday’,
Start => ‘08:00’,
End => ‘17:30’
},
4 => {
Name => ‘Thursday’,
Start => ‘08:00’,
End => ‘17:30’
},
5 => {
Name => ‘Friday’,
Start => ‘08:00’,
End => ‘17:30’
},
6 => {
Name => ‘Saturday’,
Start => undef,
End => undef
},
}
)
);

Set( %ServiceAgreements, (
Default => ‘Severity 2’,
QueueDefault => {
‘Incoming’ => ‘Severity 1’,
‘Availability Management’ => ‘Severity 2’,
‘Change Management’ => ‘Severity 2’,
‘Development Management’ => ‘Severity 2’,
‘Monitoring Management’ => ‘Severity 2’,
‘Operations Management’ => ‘Severity 2’,
‘Problem Management’ => ‘Severity 2’,
‘Project Managment’ => ‘Severity 2’,
‘Release Management’ => ‘Severity 2’,
},
‘Levels’ =>
{
‘Severity 1’ => {
StartImmediately => 1,
OutOfHours => {
Response => {
RealMinutes => 151
},
},
Respond => {
RealMinutes => 101
},
Resolve => {
RealMinutes => 601
},
},
‘Severity 2’ => {
StartImmediately => 1,
Respond => {
RealMinutes => 201
},
Resolve => {
RealMinutes => 608
},
},
‘Severity 3’ => {
StartImmediately => 1,
Respond => {
BusinessMinutes => 201
},
Resolve => {
BusinessMinutes => 608
},
},
‘Severity 4’ => {
StartImmediately => 1,
Respond => {
BusinessMinutes => 608
},
},
‘RCA’ => {
StartImmediately => 1,
Respond => {
BusinessMinutes => 201
},
Resolve => {
BusinessMinutes => 608
},
},
‘Site Operation Requests’ => {
Respond => {
BusinessMinutes => 201
},
Resolve => {
BusinessMinutes => 601
},
},
‘Site Project Requests/Enhancements’ => {
Respond => {
BusinessMinutes => 201
},
},
‘Project Support Requests’ => {
Respond => {
BusinessMinutes => 601
},
},
‘Housekeeping/ Maintenance’ => {
Respond => {
BusinessMinutes => 601
},
},
‘External access’ => {
Respond => {
BusinessMinutes => 608
},
Resolve => {
BusinessMinutes => 60*8
},
},
}
)
);

I want to know more about use case to understand if it’s possible to
improve this extension.

The use case is as explained more or less above, where the due date is
determined either via the logging and classification of the ticket, or via
contact with the requester. Most of the service levels that we have do have
very hard due dates, just a couple of categories have soft due dates.
Sometimes the due dates need to move, even in the categories that have hard
SLA due dates, simply because of incomplete information from the requester.

While we are on the topic of improvements.

I would also like to see the due date shift the amount of time that the
ticket was stalled upon re-open. For our organization we use the stalled
status to indicate that the “ball is out of our court” in other words we are
waiting for input from some other source.

Thanks,

Bill GraboyesOn Mon, Jul 6, 2009 at 10:47 AM, Ruslan Zakirov ruslan.zakirov@gmail.comwrote:

Nope, cuz SLA extension is used to automate due date management. What
are you trying to achive? How is extension is configured? I want to
know more about use case to understand if it’s possible to improve
this extension.

On Mon, Jul 6, 2009 at 9:12 PM, William Graboyeswilliam.graboyes@theportalgrp.com wrote:

Hi all,

I am having a problem with the SLA module.

Any time we change a due date, The SLA module changes it back to the
prescribed due date in the config file.

Is there any way to change this behavior?

RT Version: 3.8.4

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

–
Best regards, Ruslan.

Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

4

Hi Ruslan,

What are you trying to achive?

We have some SLA Categories that the due dates are “as mutually agreed upon”
Thus they are sending a due date along with the ticket.

How is extension is configured?Set( %ServiceBusinessHours, (

[snip]

);

I want to know more about use case to understand if it’s possible to
improve this extension.

The use case is as explained more or less above, where the due date is
determined either via the logging and classification of the ticket, or via
contact with the requester. Most of the service levels that we have do have
very hard due dates, just a couple of categories have soft due dates.
Sometimes the due dates need to move, even in the categories that have hard
SLA due dates, simply because of incomplete information from the requester.

Do I understand it right that you want to set resolve deadline
manually and keep reply deadline from the config? The only thing that
I have in mind and want to implement some day is “manual resolve
deadline”. When a person sets due date on a ticket manually then this
date used as resolve deadline and extension changes due dates
according to the current doc.

Hope that description is clear enough. Is it close to your
requirements? I can not say that it will be in the next version or any
time soon, dates guaranted only if it’s sponsored work. Patches are
always welcome at no charge.

While we are on the topic of improvements.

I would also like to see the due date shift the amount of time that the
ticket was stalled upon re-open. For our organization we use the stalled
status to indicate that the “ball is out of our court” in other words we are
waiting for input from some other source.

Sounds reasonable, but not sure how make this transparent and trigger
“re-open” event. Too many variants for different workflows. It may be
possbile to adjust scrips and come up with required setup even with
the current version, but I’m not sure.

Thanks,

Bill Graboyes

Nope, cuz SLA extension is used to automate due date management. What
are you trying to achive? How is extension is configured? I want to
know more about use case to understand if it’s possible to improve
this extension.

Hi all,

I am having a problem with the SLA module.

Any time we change a due date, The SLA module changes it back to the
prescribed due date in the config file.

Is there any way to change this behavior?

RT Version: 3.8.4

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

–
Best regards, Ruslan.

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

Best regards, Ruslan.

5

Hi Ruslan,

Do I understand it right that you want to set resolve deadline
manually and keep reply deadline from the config? The only thing that
I have in mind and want to implement some day is “manual resolve
deadline”. When a person sets due date on a ticket manually then this
date used as resolve deadline and extension changes due dates
according to the current doc.

Hope that description is clear enough. Is it close to your
requirements? I can not say that it will be in the next version or any
time soon, dates guaranted only if it’s sponsored work. Patches are
always welcome at no charge.

That sounds about right, basically I would think it could be as simple as an
if-then check… something along the lines of, if SLA hasn’t changed, then
don’t run the SLA date change… else run the sla date change. I may even
attempt to hack it out.

Yay, sandbox time.

Sounds reasonable, but not sure how make this transparent and trigger
“re-open” event. Too many variants for different workflows. It may be
possbile to adjust scrips and come up with required setup even with
the current version, but I’m not sure.

Could just add it as a config flag, time stalls when stalled… when a
ticket is coresponded to the ticket automagically changes state from stalled
to open, really could just be a scrip action based on the change of state
from stalled to opened.

if the above was implimented, with a manual due date override, the latter
would be fairly easy, just some simple time changes and math.

Thanks,
Bill GraboyesOn Mon, Jul 6, 2009 at 1:52 PM, Ruslan Zakirov ruslan.zakirov@gmail.comwrote:

On Mon, Jul 6, 2009 at 10:30 PM, William Graboyeswilliam.graboyes@theportalgrp.com wrote:

Hi Ruslan,

What are you trying to achive?

We have some SLA Categories that the due dates are “as mutually agreed
upon”
Thus they are sending a due date along with the ticket.

How is extension is configured?Set( %ServiceBusinessHours, (

[snip]

);

I want to know more about use case to understand if it’s possible to
improve this extension.

The use case is as explained more or less above, where the due date is
determined either via the logging and classification of the ticket, or
via
contact with the requester. Most of the service levels that we have do
have
very hard due dates, just a couple of categories have soft due dates.
Sometimes the due dates need to move, even in the categories that have
hard
SLA due dates, simply because of incomplete information from the
requester.

Do I understand it right that you want to set resolve deadline
manually and keep reply deadline from the config? The only thing that
I have in mind and want to implement some day is “manual resolve
deadline”. When a person sets due date on a ticket manually then this
date used as resolve deadline and extension changes due dates
according to the current doc.

Hope that description is clear enough. Is it close to your
requirements? I can not say that it will be in the next version or any
time soon, dates guaranted only if it’s sponsored work. Patches are
always welcome at no charge.

While we are on the topic of improvements.

I would also like to see the due date shift the amount of time that the
ticket was stalled upon re-open. For our organization we use the stalled
status to indicate that the “ball is out of our court” in other words we
are
waiting for input from some other source.

Sounds reasonable, but not sure how make this transparent and trigger
“re-open” event. Too many variants for different workflows. It may be
possbile to adjust scrips and come up with required setup even with
the current version, but I’m not sure.

Thanks,

Bill Graboyes

On Mon, Jul 6, 2009 at 10:47 AM, Ruslan Zakirov < ruslan.zakirov@gmail.com> wrote:

Nope, cuz SLA extension is used to automate due date management. What
are you trying to achive? How is extension is configured? I want to
know more about use case to understand if it’s possible to improve
this extension.

On Mon, Jul 6, 2009 at 9:12 PM, William Graboyeswilliam.graboyes@theportalgrp.com wrote:

Hi all,

I am having a problem with the SLA module.

Any time we change a due date, The SLA module changes it back to the
prescribed due date in the config file.

Is there any way to change this behavior?

RT Version: 3.8.4

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

–
Best regards, Ruslan.

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

–
Best regards, Ruslan.

Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

6

Hi Ruslan,

Do I understand it right that you want to set resolve deadline
manually and keep reply deadline from the config? The only thing that
I have in mind and want to implement some day is “manual resolve
deadline”. When a person sets due date on a ticket manually then this
date used as resolve deadline and extension changes due dates
according to the current doc.

Hope that description is clear enough. Is it close to your
requirements? I can not say that it will be in the next version or any
time soon, dates guaranted only if it’s sponsored work. Patches are
always welcome at no charge.

That sounds about right, basically I would think it could be as simple as an
if-then check… something along the lines of, if SLA hasn’t changed, then
don’t run the SLA date change… else run the sla date change. I may even
attempt to hack it out.

If you want to hack on it then it’s probably the best to store value
in the attribute when it’s manually set. It’s a simple scrip. Then in
the code that calculates SLA’s resolve deadline it’s possible to check
the attribute and use its value.

Yay, sandbox time.

Sounds reasonable, but not sure how make this transparent and trigger
“re-open” event. Too many variants for different workflows. It may be
possbile to adjust scrips and come up with required setup even with
the current version, but I’m not sure.

Could just add it as a config flag, time stalls when stalled… when a
ticket is coresponded to the ticket automagically changes state from stalled
to open, really could just be a scrip action based on the change of state
from stalled to opened.

if the above was implimented, with a manual due date override, the latter
would be fairly easy, just some simple time changes and math.

When we talk about response deadline, it’s pretty easy. When status is
changed to stalled then we just ignore response deadline and this can
be configurable in the config. When it’s opened again we can enable
response deadlines. This particular thing is easy. Adjust scrip
condition when we check if we should recalculate Due date. In the
scrip action that actually set due date ignore response code if the
ticket is stalled. Something like that.

It’s hard to tell what to do with resolve and keep in loop (added in
the latest version) deadlines. Should we move resolve deadline for 10
hours if it’s been stalled for 10 hours? Should we disable keep in
loop deadlines on stalled tickets or people still want to keep
customer informed? Different people want different things, so patching
extension may be isn’t that easy.

Thanks,
Bill Graboyes

Hi Ruslan,

What are you trying to achive?

We have some SLA Categories that the due dates are “as mutually agreed
upon”
Thus they are sending a due date along with the ticket.

How is extension is configured?Set( %ServiceBusinessHours, (

[snip]

);

I want to know more about use case to understand if it’s possible to
improve this extension.

The use case is as explained more or less above, where the due date is
determined either via the logging and classification of the ticket, or
via
contact with the requester. Most of the service levels that we have do
have
very hard due dates, just a couple of categories have soft due dates.
Sometimes the due dates need to move, even in the categories that have
hard
SLA due dates, simply because of incomplete information from the
requester.

Do I understand it right that you want to set resolve deadline
manually and keep reply deadline from the config? The only thing that
I have in mind and want to implement some day is “manual resolve
deadline”. When a person sets due date on a ticket manually then this
date used as resolve deadline and extension changes due dates
according to the current doc.

Hope that description is clear enough. Is it close to your
requirements? I can not say that it will be in the next version or any
time soon, dates guaranted only if it’s sponsored work. Patches are
always welcome at no charge.

While we are on the topic of improvements.

I would also like to see the due date shift the amount of time that the
ticket was stalled upon re-open. For our organization we use the
stalled
status to indicate that the “ball is out of our court” in other words we
are
waiting for input from some other source.

Sounds reasonable, but not sure how make this transparent and trigger
“re-open” event. Too many variants for different workflows. It may be
possbile to adjust scrips and come up with required setup even with
the current version, but I’m not sure.

Thanks,

Bill Graboyes

Nope, cuz SLA extension is used to automate due date management. What
are you trying to achive? How is extension is configured? I want to
know more about use case to understand if it’s possible to improve
this extension.

Hi all,

I am having a problem with the SLA module.

Any time we change a due date, The SLA module changes it back to the
prescribed due date in the config file.

Is there any way to change this behavior?

RT Version: 3.8.4

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

–
Best regards, Ruslan.

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

–
Best regards, Ruslan.

–
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312

Best regards, Ruslan.

7

Been a happy RT user for a few years now, currently running
3.8.1. For these last years, I’ve only had one active queue
for helpdesk.

I recently had reason to add a second queue for the folks
doing facilities maintainence.

All iz well. But since I now have 2 queues, I was wondering
if there was a way to differentiate them in follow-ups.

Right now, the 'Please include the string [domain.tld #xxxx]
applies to both queues. That’s fine, but it would be
nice if instead of domain.tld, I had queue1 or queue2

for the subject line string.

Basically, it’s a non issue, but I was wondering if there is
a simple way to implement this.

Thanks kindly in advance;

Chip Mefford
Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water
Public Key
http://www.well.com/user/cpm

8

You can either use the queue specific subject tags, or see my earlier
posts on this list about tweaking the codebase
to emit subjects like:

[RTname Qname ID#] Actual Subject

Either way, be sure to read perldoc RT_Config.pm thoroughly, as there
are some magic variables in there that need to be updated so that
under special circumstances the altered forms are recognized as
replies and don’t get their subject’s mangled (having a copy of the
subject tag moved to the end of the subject)
Cambridge Energy Alliance: Save money. Save the planet.

9

Have you seen subject tag feature? It’s a new property of queues you
can change via the web UI.On Wed, Jul 8, 2009 at 7:17 PM, Chip Meffordcpm@well.com wrote:

Been a happy RT user for a few years now, currently running
3.8.1. For these last years, I’ve only had one active queue
for helpdesk.

I recently had reason to add a second queue for the folks
doing facilities maintainence.

All iz well. But since I now have 2 queues, I was wondering
if there was a way to differentiate them in follow-ups.

Right now, the 'Please include the string [domain.tld #xxxx]
applies to both queues. That’s fine, but it would be
nice if instead of domain.tld, I had queue1 or queue2

for the subject line string.

Basically, it’s a non issue, but I was wondering if there is
a simple way to implement this.

Thanks kindly in advance;

–

Chip Mefford

Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water

Public Key
Chip Mefford's public key

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

10

Ruslan Zakirov wrote:

Have you seen subject tag feature? It’s a new property of queues you
can change via the web UI.

Hey Ruslan;

yes, That part I get, however the body of the auto reply
contains contradictory info.

While the subject will say:

[queue-name ID#] Blah blah blah,

in the body of the actual auto reply, it will restate:
…
Your ticket has been assigned an ID of [queue-name ID#].

Please include the string:

[domain.tld ID#]

in the subject line of all future…

which is contradictory.

I hope I am making this clear.> > On Wed, Jul 8, 2009 at 7:17 PM, Chip Meffordcpm@well.com wrote:

Been a happy RT user for a few years now, currently running
3.8.1. For these last years, I’ve only had one active queue
for helpdesk.

I recently had reason to add a second queue for the folks
doing facilities maintainence.

All iz well. But since I now have 2 queues, I was wondering
if there was a way to differentiate them in follow-ups.

Right now, the 'Please include the string [domain.tld #xxxx]
applies to both queues. That’s fine, but it would be
nice if instead of domain.tld, I had queue1 or queue2

for the subject line string.

Basically, it’s a non issue, but I was wondering if there is
a simple way to implement this.

Thanks kindly in advance;

–

Chip Mefford

Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water

Public Key
Chip Mefford's public key

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Chip Mefford
Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water
Public Key
http://www.well.com/user/cpm

11

Fix templates, use the following code in them:

{$Ticket->QueueObj->SubjectTag || $rtname}On Wed, Jul 8, 2009 at 8:15 PM, Chip Meffordcpm@well.com wrote:

Ruslan Zakirov wrote:

Have you seen subject tag feature? It’s a new property of queues you
can change via the web UI.

Hey Ruslan;

yes, That part I get, however the body of the auto reply
contains contradictory info.

While the subject will say:

[queue-name ID#] Blah blah blah,

in the body of the actual auto reply, it will restate:

…
Your ticket has been assigned an ID of [queue-name ID#].

Please include the string:

[domain.tld ID#]

in the subject line of all future…

which is contradictory.

I hope I am making this clear.

On Wed, Jul 8, 2009 at 7:17 PM, Chip Meffordcpm@well.com wrote:

Been a happy RT user for a few years now, currently running
3.8.1. For these last years, I’ve only had one active queue
for helpdesk.

I recently had reason to add a second queue for the folks
doing facilities maintainence.

All iz well. But since I now have 2 queues, I was wondering
if there was a way to differentiate them in follow-ups.

Right now, the 'Please include the string [domain.tld #xxxx]
applies to both queues. That’s fine, but it would be
nice if instead of domain.tld, I had queue1 or queue2

for the subject line string.

Basically, it’s a non issue, but I was wondering if there is
a simple way to implement this.

Thanks kindly in advance;

–

Chip Mefford

Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water

Public Key
Chip Mefford's public key

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Chip Mefford

Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water

Public Key
Chip Mefford's public key

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

12

Ruslan Zakirov wrote:

Fix templates, use the following code in them:

{$Ticket->QueueObj->SubjectTag || $rtname}

Err, a bit out of my depth I guess. Not sure
where to do this, not keen on fiddling Templates_Overlay.pm
or similar. And not clueful on how to add queue specific stuff
in the configuration menu

thanks though, read the book a bit more I suppose.
Chip Mefford
Before Enlightenment;
chop wood
carry water
After Enlightenment;
chop wood
carry water
Public Key
http://www.well.com/user/cpm

13

Ruslan Zakirov wrote:

Fix templates, use the following code in them:

{$Ticket->QueueObj->SubjectTag || $rtname}

Err, a bit out of my depth I guess. Not sure
where to do this, not keen on fiddling Templates_Overlay.pm
or similar. And not clueful on how to add queue specific stuff
in the configuration menu

Configuration → Templates → Autoreply

Just paste in what Ruz wrote, which should be the
default on an installed 3.8, but possibly not on
an upgraded 3.8

-kevin

14

Hi All,

I finally got time to come up with a solution to the problem I was having.

sub IsApplicable {
my $self = shift;
return 0 unless $self->SLAIsApplied;

my $type = $self->TransactionObj->Type;
if ( $type eq 'Create' || $type eq 'Correspond' ) {
    if ($self->TicketObj->FirstCustomFieldValue('SLA') eq 'Severity 4'){
        return 0;
    }
    if ($self->TicketObj->FirstCustomFieldValue('SLA') eq 'Severity 1'

|| $self->TicketObj->FirstCustomFieldValue(‘SLA’) eq 'Severity …
return 1;
}
else {
return 0;
}
}
return 1 if $self->IsCustomFieldChange(‘SLA’);
return 0;
}
This does excactly what I want it to do.

Skips setting the Due date for Sev 4 tickets.

and sets the due dates on the rest.

Thanks,
Bill Graboyes