Difference between revisions of "ConfigureEscalation"

From Request Tracker Wiki
Jump to navigation Jump to search
m (2 revisions imported)
 
m
 
Line 29: Line 29:
== How to use this ==
== How to use this ==


# The [[EscalatePriority]] module is pre-installed with RT.
1. The [[EscalatePriority]] module is pre-installed with RT.
# [[EscalatePriorityLinear]].pm can be copied to <code>local/lib/RT/Action/</code>. If you scrape it off the web, make sure to remove leading space from all of the POD lines (beginning with the = sign), and confirm that it compiles with [=perl -c [[EscalatePriorityLinear]].pm].
2. [[EscalatePriorityLinear]].pm can be copied to <code>local/lib/RT/Action/</code>. If you scrape it off the web, make sure to remove leading space from all of the POD lines (beginning with the = sign), and confirm that it compiles with [=perl -c [[EscalatePriorityLinear]].pm].
# Setup the starting priority, final priority and default due date for a queue in the [[QueueProperties]] configuration, and/or let users adjust final priority and due date on individual tickets.
3. Setup the starting priority, final priority and default due date for a queue in the [[QueueProperties]] configuration, and/or let users adjust final priority and due date on individual tickets.
# Setup cron to call rt-crontool once every 24 hours. It is easy to set up escalation to be queue-specific or based on any TicketSQL conditions you want. This [[ConfigureEscalationExample]] is a wrapper script that escalates priority for all queues. Here is [[AnotherConfigurationEscalationExample]].
4. Setup cron to call rt-crontool once every 24 hours. It is easy to set up escalation to be queue-specific or based on any TicketSQL conditions you want. This [[ConfigureEscalationExample]] is a wrapper script that escalates priority for all queues. Here is [[AnotherConfigurationEscalationExample]].
# Set [[ShowTicket]] and [[ModifyTicket]] Global permissions for the cron account.
5. Set [[ShowTicket]] and [[ModifyTicket]] Global permissions for the cron account.
# Verify that escalation is working.
6. Verify that escalation is working.


Note: One additional use of escalation, is to send email reminders, using a script such as [http://www.cs.kent.ac.uk/people/staff/tdb/rt3/ rt-remind].
Note: One additional use of escalation, is to send email reminders, using a script such as [http://www.cs.kent.ac.uk/people/staff/tdb/rt3/ rt-remind].

Latest revision as of 17:35, 11 November 2016

A quick background on escalation

A ticket is escalated by the RT::Action::EscalatePriority module or unofficial RT::Action::EscalatePriorityLinear module. Either module must be invoked by an escalation tool, such as the included $RTHOME/bin/rt-crontool.

EscalatePriority uses the following formula to change a ticket's priority:

Priority = Priority +  (( FinalPriority - Priority ) / ( DueDate-Today))

... unless the due date is in the past, in which case the priority is bumped straight to the final priority. In this way, the priority of the ticket is either increased or decreased toward the final priority as the ticket heads toward its due date.

... unless the due date is not set, in which case the priority is incremented or decremented by 1 towards the final priority.

EscalatePriorityLinear uses the following formula to change a ticket's priority:

Priority = FinalPriority * (Now-Starts) / (DueDate-Starts)

... unless the due date is in the past, in which case priority gets bumped straight to final priority. Unlike RT::Action::EscalatePriority, priority is not decreased if it's above FinalPriority.

Caveats

  • For the EscalatePriority module, priority does not change gradually in proportion with the amount of time passed. Instead, all of the change occurs in the last X days of the ticket, where X is the priority difference. This makes this module not very useful 1) for very long-term tickets such as might be used to guide software development or other project management, and 2) for situations where you use a small priority range (e.g. 0-5 or 0-20).
  • If final priorities and/or due dates have been experimentally or carelessly assigned to tickets prior to implementing escalation, you may be surprised to see priorities on these tickets changing when you turn on escalation. This is especially annoying if users have innocently assigned a due date without adding a final priority, because the priority will "escalate" to zero. You can tune your invocation of rt-crontool to avoid this problem.

How to use this

1. The EscalatePriority module is pre-installed with RT. 2. EscalatePriorityLinear.pm can be copied to local/lib/RT/Action/. If you scrape it off the web, make sure to remove leading space from all of the POD lines (beginning with the = sign), and confirm that it compiles with [=perl -c EscalatePriorityLinear.pm]. 3. Setup the starting priority, final priority and default due date for a queue in the QueueProperties configuration, and/or let users adjust final priority and due date on individual tickets. 4. Setup cron to call rt-crontool once every 24 hours. It is easy to set up escalation to be queue-specific or based on any TicketSQL conditions you want. This ConfigureEscalationExample is a wrapper script that escalates priority for all queues. Here is AnotherConfigurationEscalationExample. 5. Set ShowTicket and ModifyTicket Global permissions for the cron account. 6. Verify that escalation is working.

Note: One additional use of escalation, is to send email reminders, using a script such as rt-remind.