ConfigureEscalation

From Request Tracker Wiki
Revision as of 17:35, 11 November 2016 by Singular error (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.