Can I 'parked' stalled tickets?

Hi all,

I’ve been working with RT 4.05 and have added the SLA Extension [v.0.06] to it.

We’re using some simple SLA rules - no respond or keepinloop rules, just resolve rules. Generally, all tickets should be resolved within x Days from ticket creation.

Eg;

            'Normal' => {
                    Resolve => { BusinessMinutes => 60*8*5, IgnoreOnStatuses => ['stalled']  }, # Within 5 Working Days
                    },

We’re using Business:Hours to make sure weekend and public holidays aren’t counted.

Jobs start at Priority 0 and via an hourly LinearEscalate Cron job, escalate to Priority 100 the closer they get to the due date. So a job with a 5 working day SLA will be at Priority 40 after 2 business days.

Now - as a basic setup, it’s all working nicely. (And I’d like to say - I love the program!)

There’s just ONE thing not working the way we’d like and I suspect I’ve missed something, so I’d appreciate a second opinion.

You’ll notice we’ve got “IgnoreOnStatuses => [‘stalled’]” in there. If we make a job and stall it, the priority does NOT advance. All good so far.

However when the job is changed from stalled back to open, it doesn’t punch the Due Date out according to the time it was stalled. So - a job is due 5 days after it’s created. If we stall the job after 4 hours, the priority will freeze at 10. If we change the job back to “open” 2 days later, the due date remains unchanged and the job will still be due in another 2.5 days. Next time the LinearEscalate cron job runs, the Priority jumps right up to 50.

What we WANT it to do, is - when we un-stall the job 2 days later, we want RT to automatically extend the Due Date by the same amount of time it was stalled - in this case, 2 days.

Any thoughts? What’ve I missed?

= Dave Fitches =

.,–|… David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.aublocked::blocked::mailto:dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia

Have a look at my customization for parking stalled tickets (actually it works for SLA 0.05)

If you make any improvements, please share them :slight_smile:

Alberto Scotto

[Blue]
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto@reply.it
www.reply.itFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Dave Fitches
Sent: venerdì 24 agosto 2012 06:40
To: rt-users@lists.bestpractical.com
Subject: [rt-users] [SLA Extension] Can I ‘parked’ stalled tickets?

Hi all,

I’ve been working with RT 4.05 and have added the SLA Extension [v.0.06] to it.

We’re using some simple SLA rules - no respond or keepinloop rules, just resolve rules. Generally, all tickets should be resolved within x Days from ticket creation.

Eg;

            'Normal' => {
                    Resolve => { BusinessMinutes => 60*8*5, IgnoreOnStatuses => ['stalled']  }, # Within 5 Working Days
                    },

We’re using Business:Hours to make sure weekend and public holidays aren’t counted.

Jobs start at Priority 0 and via an hourly LinearEscalate Cron job, escalate to Priority 100 the closer they get to the due date. So a job with a 5 working day SLA will be at Priority 40 after 2 business days.

Now - as a basic setup, it’s all working nicely. (And I’d like to say - I love the program!)

There’s just ONE thing not working the way we’d like and I suspect I’ve missed something, so I’d appreciate a second opinion.

You’ll notice we’ve got “IgnoreOnStatuses => [‘stalled’]” in there. If we make a job and stall it, the priority does NOT advance. All good so far.

However when the job is changed from stalled back to open, it doesn’t punch the Due Date out according to the time it was stalled. So - a job is due 5 days after it’s created. If we stall the job after 4 hours, the priority will freeze at 10. If we change the job back to “open” 2 days later, the due date remains unchanged and the job will still be due in another 2.5 days. Next time the LinearEscalate cron job runs, the Priority jumps right up to 50.

What we WANT it to do, is - when we un-stall the job 2 days later, we want RT to automatically extend the Due Date by the same amount of time it was stalled - in this case, 2 days.

Any thoughts? What’ve I missed?

= Dave Fitches =

.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia

The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

However when the job is changed from stalled back to open, it doesn’t punch the Due Date out
according to the time it was stalled. So - a job is due 5 days after it’s created. If we stall
the job after 4 hours, the priority will freeze at 10. If we change the job back to “open” 2
days later, the due date remains unchanged and the job will still be due in another 2.5 days.
Next time the LinearEscalate cron job runs, the Priority jumps right up to 50.

What we WANT it to do, is - when we un-stall the job 2 days later, we want RT to automatically
extend the Due Date by the same amount of time it was stalled - in this case, 2 days.

Unfortunately, you’re likely going to need some customizations there,
the doc for IgnoreOnStatuses has the following note about
recalculating Due:

NOTE: When a ticket goes from an ignored status to a normal status, the
new Due date is calculated from the last action (reply, SLA change, etc)
which fits the SLA type (Response, Starts, KeepInLoop, etc). This means
if a ticket in the above example flips from stalled to open without a
reply, the ticket will probably be overdue. In most cases this shouldn't
be a problem since moving out of stalled-like statuses is often the
result of RT's auto-open on reply scrip, therefore ensuring there's a
new reply to calculate Due from. The overall effect is that ignored
statuses don't let the Due date drift arbitrarily, which could wreak
havoc on your SLA performance.

This is a new feature in 0.06, and patches to extend the behavior would
probably be interesting to my colleagues who worked on the feature.

-kevin

Sorry, the version of SLA extension shouldn’t matter.

Alberto Scotto

[Blue]
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto@reply.it
www.reply.itFrom: Scotto Alberto
Sent: venerdì 24 agosto 2012 17:01
To: Dave Fitches; rt-users@lists.bestpractical.com
Subject: RE: [SLA Extension] Can I ‘parked’ stalled tickets?

Have a look at my customization for parking stalled tickets (actually it works for SLA 0.05)

If you make any improvements, please share them :slight_smile:

Alberto Scotto

[Blue]
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto@reply.it
www.reply.it

From: rt-users-bounces@lists.bestpractical.commailto:rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com]mailto:[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Dave Fitches
Sent: venerdì 24 agosto 2012 06:40
To: rt-users@lists.bestpractical.commailto:rt-users@lists.bestpractical.com
Subject: [rt-users] [SLA Extension] Can I ‘parked’ stalled tickets?

Hi all,

I’ve been working with RT 4.05 and have added the SLA Extension [v.0.06] to it.

We’re using some simple SLA rules - no respond or keepinloop rules, just resolve rules. Generally, all tickets should be resolved within x Days from ticket creation.

Eg;

            'Normal' => {
                    Resolve => { BusinessMinutes => 60*8*5, IgnoreOnStatuses => ['stalled']  }, # Within 5 Working Days
                    },

We’re using Business:Hours to make sure weekend and public holidays aren’t counted.

Jobs start at Priority 0 and via an hourly LinearEscalate Cron job, escalate to Priority 100 the closer they get to the due date. So a job with a 5 working day SLA will be at Priority 40 after 2 business days.

Now - as a basic setup, it’s all working nicely. (And I’d like to say - I love the program!)

There’s just ONE thing not working the way we’d like and I suspect I’ve missed something, so I’d appreciate a second opinion.

You’ll notice we’ve got “IgnoreOnStatuses => [‘stalled’]” in there. If we make a job and stall it, the priority does NOT advance. All good so far.

However when the job is changed from stalled back to open, it doesn’t punch the Due Date out according to the time it was stalled. So - a job is due 5 days after it’s created. If we stall the job after 4 hours, the priority will freeze at 10. If we change the job back to “open” 2 days later, the due date remains unchanged and the job will still be due in another 2.5 days. Next time the LinearEscalate cron job runs, the Priority jumps right up to 50.

What we WANT it to do, is - when we un-stall the job 2 days later, we want RT to automatically extend the Due Date by the same amount of time it was stalled - in this case, 2 days.

Any thoughts? What’ve I missed?

= Dave Fitches =

.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia

The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Morning Alberto,

I DID find that article previously, but I have to say (embarrassingly) that I couldn’t work it out (Seems I’m a tad thick with some things) and the last reply by Ruslan lead me to believe he’d incorporated it into 0.06 - but that appears to be just the priority hold, not the re-calculate due date part.

You say to use two conditions “on stall”/“on un-stall”- but I’m having trouble working out how to create the “on stalled”/“on un-stall” conditions.

I found this: http://requesttracker.wikia.com/wiki/OnStatusChange

It looks like a MySQL command… and it should give me the “On Stall” condition, but I’m unsure how to get the UN-stall condition with the same method…

I’m fairly certain the code for Action1 and Action2 go in as User Defined Actions into the “Custom action cleanup code” area, yes?

So in the end - once I figure out how to create the two custom conditions, I then create two Scrips:

Scrip1:
	Name:	[SLA] Parking ticket 
	Condition: On Stall
	User Defined Action - <Action1>

Scrip2:
	Name: [SLA] Unparking Ticket 
	Condition: On Un-Stall
	User Defined Action - <Action2>

These SHOULD then do the job of punching out the due date by the period of time the ticket was stalled - yes?

Thanks in advance for all the assistance!

= Dave Fitches =

.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia

Hi,

Morning Alberto,

I DID find that article previously, but I have to say
(embarrassingly) that I couldn’t work it out (Seems I’m a tad thick
with some things) and the last reply by Ruslan lead me to believe he’d
incorporated it into 0.06 - but that appears to be just the priority
hold, not the re-calculate due date part.

Which article?

Have you seen the following option:

You say to use two conditions “on stall”/“on un-stall”- but I’m having trouble working out how to create the “on stalled”/“on un-stall” conditions.

I found this: http://requesttracker.wikia.com/wiki/OnStatusChange

It looks like a MySQL command… and it should give me the “On Stall” condition, but I’m unsure how to get the UN-stall condition with the same method…

I’m fairly certain the code for Action1 and Action2 go in as User Defined Actions into the “Custom action cleanup code” area, yes?

So in the end - once I figure out how to create the two custom conditions, I then create two Scrips:

    Scrip1:
            Name:   [SLA] Parking ticket
            Condition: On Stall
            User Defined Action - <Action1>

    Scrip2:
            Name: [SLA] Unparking Ticket
            Condition: On Un-Stall
            User Defined Action - <Action2>

These SHOULD then do the job of punching out the due date by the period of time the ticket was stalled - yes?

Thanks in advance for all the assistance!


= Dave Fitches =


.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia


Best regards, Ruslan.

However when the job is changed from stalled back to open, it doesn’t punch the Due Date out
according to the time it was stalled. So - a job is due 5 days after it’s created. If we stall
the job after 4 hours, the priority will freeze at 10. If we change the job back to “open” 2
days later, the due date remains unchanged and the job will still be due in another 2.5 days.
Next time the LinearEscalate cron job runs, the Priority jumps right up to 50.

What we WANT it to do, is - when we un-stall the job 2 days later, we want RT to automatically
extend the Due Date by the same amount of time it was stalled - in this case, 2 days.

Unfortunately, you’re likely going to need some customizations there,
the doc for IgnoreOnStatuses has the following note about
recalculating Due:

NOTE: When a ticket goes from an ignored status to a normal status, the
new Due date is calculated from the last action (reply, SLA change, etc)
which fits the SLA type (Response, Starts, KeepInLoop, etc). This means
if a ticket in the above example flips from stalled to open without a
reply, the ticket will probably be overdue. In most cases this shouldn't
be a problem since moving out of stalled-like statuses is often the
result of RT's auto-open on reply scrip, therefore ensuring there's a
new reply to calculate Due from. The overall effect is that ignored
statuses don't let the Due date drift arbitrarily, which could wreak
havoc on your SLA performance.

This is a new feature in 0.06, and patches to extend the behavior would
probably be interesting to my colleagues who worked on the feature.

Ignore my other reply with questions. That message felt out the thread
in my MUA.

As Kevin mentioned IgnoreOnStatuses designed this way on purpose. This
option is more suitable for Reply and KeepInLoop deadlines.

Instead of changing how above option works I would prefer to see a new
option special for Resolve deadline that moves Due date when ticket is
"parked/unparked".

I can not say I’m going to implement it soon. Patches are welcome.

-kevin

Best regards, Ruslan.

Hi Ruslan,

0.07 is the version I’m running.

Does it need any modification to punch out expiry dates when un-stalled?

Presently when I un-stall a job, it’s not doing it… hence why I was looking at Alberto’s solution… I just need to try and work out how to implement it!

= Dave Fitches =

.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia
Please Note: Unless this e-mail has been sent as PRIVATE,
PERSONAL or CONFIDENTIAL, the receiver may forward copies
of it on the condition that they send an advisory message
to the original sender.
If however the message has been marked PRIVATE, PERSONAL
or CONFIDENTIAL prior consent MUST be obtained before the
message can be forwarded.From: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov
Sent: Tuesday, 28 August 2012 09:56
To: Dave Fitches
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] [SLA Extension] Can I ‘parked’ stalled tickets?

Hi,

Morning Alberto,

I DID find that article previously, but I have to say
(embarrassingly) that I couldn’t work it out (Seems I’m a tad thick
with some things) and the last reply by Ruslan lead me to believe he’d
incorporated it into 0.06 - but that appears to be just the priority
hold, not the re-calculate due date part.

Which article?

Have you seen the following option:

You say to use two conditions “on stall”/“on un-stall”- but I’m having trouble working out how to create the “on stalled”/“on un-stall” conditions.

I found this: http://requesttracker.wikia.com/wiki/OnStatusChange

It looks like a MySQL command… and it should give me the “On Stall” condition, but I’m unsure how to get the UN-stall condition with the same method…

I’m fairly certain the code for Action1 and Action2 go in as User Defined Actions into the “Custom action cleanup code” area, yes?

So in the end - once I figure out how to create the two custom conditions, I then create two Scrips:

    Scrip1:
            Name:   [SLA] Parking ticket
            Condition: On Stall
            User Defined Action - <Action1>

    Scrip2:
            Name: [SLA] Unparking Ticket
            Condition: On Un-Stall
            User Defined Action - <Action2>

These SHOULD then do the job of punching out the due date by the period of time the ticket was stalled - yes?

Thanks in advance for all the assistance!


= Dave Fitches =


.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia


Best regards, Ruslan.

Hi Ruslan,

0.07 is the version I’m running.

Does it need any modification to punch out expiry dates when un-stalled?

Presently when I un-stall a job, it’s not doing it… hence why I was looking at Alberto’s solution… I just need to try and work out how to implement it!

Replied in different thread.


= Dave Fitches =


.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia


Please Note: Unless this e-mail has been sent as PRIVATE,
PERSONAL or CONFIDENTIAL, the receiver may forward copies
of it on the condition that they send an advisory message
to the original sender.
If however the message has been marked PRIVATE, PERSONAL
or CONFIDENTIAL prior consent MUST be obtained before the
message can be forwarded.

-----Original Message-----
From: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov
Sent: Tuesday, 28 August 2012 09:56
To: Dave Fitches
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] [SLA Extension] Can I ‘parked’ stalled tickets?

Hi,

Morning Alberto,

I DID find that article previously, but I have to say
(embarrassingly) that I couldn’t work it out (Seems I’m a tad thick
with some things) and the last reply by Ruslan lead me to believe he’d
incorporated it into 0.06 - but that appears to be just the priority
hold, not the re-calculate due date part.

Which article?

Have you seen the following option:

RT::Extension::SLA - Service Level Agreements for RT - metacpan.org

You say to use two conditions “on stall”/“on un-stall”- but I’m having trouble working out how to create the “on stalled”/“on un-stall” conditions.

I found this: http://requesttracker.wikia.com/wiki/OnStatusChange

It looks like a MySQL command… and it should give me the “On Stall” condition, but I’m unsure how to get the UN-stall condition with the same method…

I’m fairly certain the code for Action1 and Action2 go in as User Defined Actions into the “Custom action cleanup code” area, yes?

So in the end - once I figure out how to create the two custom conditions, I then create two Scrips:

    Scrip1:
            Name:   [SLA] Parking ticket
            Condition: On Stall
            User Defined Action - <Action1>

    Scrip2:
            Name: [SLA] Unparking Ticket
            Condition: On Un-Stall
            User Defined Action - <Action2>

These SHOULD then do the job of punching out the due date by the period of time the ticket was stalled - yes?

Thanks in advance for all the assistance!


= Dave Fitches =


.,–|.. David Fitches - Security Software Admin
/ |. University of Melbourne - Access Control
_,–
/… * Ph/Mob : +61-3-8344-9232 / +61-411-811-525
…v… * E-mail : dfitches@unimelb.edu.au
… University of Melbourne, Victoria, Australia



Best regards, Ruslan.

Best regards, Ruslan.