RT 4.4: Configuring escalations with various rt-crontool options, but none are working

Hello everyone.

Currently we are quite stuck on enabling ticket escalations based on
SLA. The problem is that none of the escalation we tried seems to work:
either the crontool throws errors or does basically nothing.

What we did so far:

  • Upgrade to 4.4.1 and made sure all database migrations pass
  • Defined a basic ServiceAgreements section (code found later in this email)
  • Used an existing, working queue to enable “SLA Enabled”
  • Set the default value for “Final Priority” of this queue to “99”
  • Set the default value for “Priority” of this queue to “0”
  • Created some test tickets (via web and via email) in this queue.
    “Starts” and “Due” are correctly set according to the defined
    ServiceAgreements.

The queue we currently use for our tests is called “Test-Queue”, and
there is currently one ticket in it having “Starts” and “Due” set, the
ID is #78735.

I would appreciate if anyone has ideas on what is wrong with our setup,
or could provide a working configuration!

Here are our ServiceAgreements (just for testing so far) and some of the
rt-crontool calls and their returns we tried so far:

Set( %ServiceAgreements, (
Default => ‘standard’,
Levels => {
‘standard’ => {
Starts => { RealMinutes => 0 },
Resolve => { RealMinutes => 10 },
},
‘urgent’ => {
Starts => { RealMinutes => 0 },
Resolve => { RealMinutes => 5 },
},
},
));

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue --search-arg

“Test-Queue” -action RT::Action::EscalatePriority --verbose --log info
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

bin/rt-crontool --search RT::Search::FromSQL --search-arg

“(Status=‘new’ OR Status=‘open’) AND FinalPriority > 0 AND Due > ‘Jan 1,
1970’” --action RT::Action::EscalatePriority --action-arg
"RecordTransaction: 1, UpdateLastUpdated: 1" --verbose --log info
[11753] [Mon Feb 13 13:48:02 2017] [notice]: Passed a unix time less
than 0, forcing to 0: [-3600] (/opt/rt4/bin/…/lib/RT/Date.pm:619)
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

bin/rt-crontool --search RT::Search::FromSQL --search-arg

“(Status=‘new’ OR Status=‘open’ OR Status = ‘stalled’)” --action
RT::Action::LinearEscalate --action-arg “RecordTransaction: 1”
[11875] [Mon Feb 13 13:53:02 2017] [notice]: Passed a unix time less
than 0, forcing to 0: [-1] (/opt/rt4/bin/…/lib/RT/Date.pm:619)

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue --search-arg

“Test-Queue” -action RT::Action::LinearEscalate
[11893] [Mon Feb 13 13:55:47 2017] [warning]: Use of uninitialized value
$args{“VALUE”} in join or string at /opt/rt4/bin/…/lib/RT/Tickets.pm
line 1536. (/opt/rt4/bin/…/lib/RT/Tickets.pm:1536)
[11893] [Mon Feb 13 13:55:47 2017] [warning]: Use of uninitialized value
$value in substitution (s///) at /opt/rt4/bin/…/lib/RT/Tickets.pm line
2805. (/opt/rt4/bin/…/lib/RT/Tickets.pm:2805)

(this one is really strange, as this ticket #11893 was resolved 5 years
ago and in another queue, it should not get found by ActiveTicketsInQueue)

bin/rt-crontool --search RT::Search::FromSQL --search-arg 'Status =

“open” or Status = “new”’ --action RT::Action::LinearEscalate
–action-arg “UpdateLastUpdated: 0” --verbose --log info
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument
Action prepared…
Action committed.

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue

–search-arg Test-Queue --action RT::Action::EscalatePriority --verbose
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue

–search-arg Test-Queue --condition RT::Condition::Overdue --action
RT::Action::SetPriority --action-arg 99 --verbose
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

Kind regards,
Daniel Rauer

Nobody with an idea on how we can make any progress with escalations?
Any input would be helpful, like working config snippets, rt-crontool
calls that works for someone, …

Bye, DanielOn 02/13/2017 03:04 PM, Daniel Rauer wrote:

Hello everyone.

Currently we are quite stuck on enabling ticket escalations based on
SLA. The problem is that none of the escalation we tried seems to work:
either the crontool throws errors or does basically nothing.

What we did so far:

  • Upgrade to 4.4.1 and made sure all database migrations pass
  • Defined a basic ServiceAgreements section (code found later in this email)
  • Used an existing, working queue to enable “SLA Enabled”
  • Set the default value for “Final Priority” of this queue to “99”
  • Set the default value for “Priority” of this queue to “0”
  • Created some test tickets (via web and via email) in this queue.
    “Starts” and “Due” are correctly set according to the defined
    ServiceAgreements.

The queue we currently use for our tests is called “Test-Queue”, and
there is currently one ticket in it having “Starts” and “Due” set, the
ID is #78735.

I would appreciate if anyone has ideas on what is wrong with our setup,
or could provide a working configuration!

Here are our ServiceAgreements (just for testing so far) and some of the
rt-crontool calls and their returns we tried so far:

Set( %ServiceAgreements, (
Default => ‘standard’,
Levels => {
‘standard’ => {
Starts => { RealMinutes => 0 },
Resolve => { RealMinutes => 10 },
},
‘urgent’ => {
Starts => { RealMinutes => 0 },
Resolve => { RealMinutes => 5 },
},
},
));

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue --search-arg

“Test-Queue” -action RT::Action::EscalatePriority --verbose --log info
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

bin/rt-crontool --search RT::Search::FromSQL --search-arg

“(Status=‘new’ OR Status=‘open’) AND FinalPriority > 0 AND Due > ‘Jan 1,
1970’” --action RT::Action::EscalatePriority --action-arg
"RecordTransaction: 1, UpdateLastUpdated: 1" --verbose --log info
[11753] [Mon Feb 13 13:48:02 2017] [notice]: Passed a unix time less
than 0, forcing to 0: [-3600] (/opt/rt4/bin/…/lib/RT/Date.pm:619)
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

bin/rt-crontool --search RT::Search::FromSQL --search-arg

“(Status=‘new’ OR Status=‘open’ OR Status = ‘stalled’)” --action
RT::Action::LinearEscalate --action-arg “RecordTransaction: 1”
[11875] [Mon Feb 13 13:53:02 2017] [notice]: Passed a unix time less
than 0, forcing to 0: [-1] (/opt/rt4/bin/…/lib/RT/Date.pm:619)

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue --search-arg

“Test-Queue” -action RT::Action::LinearEscalate
[11893] [Mon Feb 13 13:55:47 2017] [warning]: Use of uninitialized value
$args{“VALUE”} in join or string at /opt/rt4/bin/…/lib/RT/Tickets.pm
line 1536. (/opt/rt4/bin/…/lib/RT/Tickets.pm:1536)
[11893] [Mon Feb 13 13:55:47 2017] [warning]: Use of uninitialized value
$value in substitution (s///) at /opt/rt4/bin/…/lib/RT/Tickets.pm line
2805. (/opt/rt4/bin/…/lib/RT/Tickets.pm:2805)

(this one is really strange, as this ticket #11893 was resolved 5 years
ago and in another queue, it should not get found by ActiveTicketsInQueue)

bin/rt-crontool --search RT::Search::FromSQL --search-arg 'Status =

“open” or Status = “new”’ --action RT::Action::LinearEscalate
–action-arg “UpdateLastUpdated: 0” --verbose --log info
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument
Action prepared…
Action committed.

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue

–search-arg Test-Queue --action RT::Action::EscalatePriority --verbose
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

bin/rt-crontool --search RT::Search::ActiveTicketsInQueue

–search-arg Test-Queue --condition RT::Condition::Overdue --action
RT::Action::SetPriority --action-arg 99 --verbose
78735:
Processing without transaction, some conditions and actions may fail.
Consider using --transaction argument

Kind regards,
Daniel Rauer

Nobody with an idea on how we can make any progress with escalations?
Any input would be helpful, like working config snippets, rt-crontool
calls that works for someone, …

Bye, Daniel

Hi Daniel,

We are still working on our upgrade to 4.4.x, but we had very poor luck
with using escalations in our current version. The priorities did increase,
but without any additional resources being allocated, the result was every
ticket eventually being at the maximum priority. That means the priority
then was useless as a differentiator. The take-away, is that you should
only consider automatic priority escalation, if and only if additional resources
WILL be allocated.

Regards,
Ken

Thanks Ken! Anyone else that has an idea or working config? Currently it seems to me that this module is neither completely documented, or even not completely implemented?

Bye, Daniel