Subject: priority escalation details

RT Developers
1

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?

Kevin, are you using rt-escalate?

http://wiki.bestpractical.com/index.cgi?Contributions

Scroll down to External Utils.

We use this for tickets due anywhere from 5 business days to 90+ business
days out. Default start priority at 11 and end at 99. This appears to be
what you’re asking for, if I understand your problem correctly.

joe

2

[Joseph Micciche]

We use this for tickets due anywhere from 5 business days to 90+
business days out. Default start priority at 11 and end at 99. This
appears to be what you’re asking for, if I understand your problem
correctly.

I suspect he is talking about tickets with even longer due periods,
where the RT::Action::EscalatePriority() function will fail to
increase the priority linearly until the due date draws close, and
then start to increase it.

If you want the priority to move from 1 to 99 over 300 days, it will
stay on 1 until there is 99 days left, and the start to increase one
per day. I would prefer it to increase priority by one every three
day or so.