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

[Daniel Rauer]

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