Priority escalation details

Hi,

Priority escalation doesn’t work the way my users and I expect. It
would seem more natural for the priority to change gradually over time
in proportion to the amount of time passed. While the current algorithm
is fine for tickets with fast turn-around, it is useless for long-term
tickets, such as would be used to track software development or other
project management tasks. The current algorithm unnecessarily limits
RT, whereas linear priority escalation would work fine for many
different applications.

What changes to RT would be needed to allow time-linear priority
escalation? Another ticket property (escalation_days_per_point or
something) that would be implicitly updated whenever the due date or
final priority is changed?

Thanks,
Kevin Murphy

[Kevin Murphy]

What changes to RT would be needed to allow time-linear priority
escalation? Another ticket property (escalation_days_per_point or
something) that would be implicitly updated whenever the due date or
final priority is changed?

The code doing the escalation is in lib/RT/Action/EscalatePriority.pm.
Rewriting the calculations to not use integer division should solve
your problem.

Our user would in addition have escalation without changing
last-updated-by, to be able to search out the tickets were someone
else than the owner was the last to update the ticket, and thus find
the tickets in need of the owners attention. Not sure how hard it
would be to make it an option for the escalation system.