ConfigureEscalation: Difference between revisions
m (2 revisions imported) |
(No difference)
|
Revision as of 15:03, 6 April 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).
- For the EscalatePriorityLinear module, the initial priority is ignored and assumed to be zero.
- 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
- The EscalatePriority module is pre-installed with RT.
- 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]. - 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.
- Set ShowTicket and ModifyTicket Global permissions for the cron account.
- Verify that escalation is working.
Note: One additional use of escalation, is to send email reminders, using a script such as rt-remind.