AnotherConfigurationEscalationExample: Difference between revisions

From Request Tracker Wiki
Jump to navigation Jump to search
m (2 revisions imported)
 
(No difference)

Latest revision as of 15:03, 6 April 2016

Escalating by queue

The canonical RT escalation example, which escalates active tickets in a given queue:

[= $RTROOT/bin/rt-crontool --search RT::Search::ActiveTicketsInQueue --search-arg YOUR_QUEUE_NAME_HERE --action RT::Action::EscalatePriority ]

Escalating by arbitrary conditions

Instead of using RT::Search::ActiveTicketsInQueue, you can use RT::Search::FromSQL and specify arbitrary TicketSQL conditions.

The following example escalates tickets (in all queues) that are either new or open, /and/ have a non-zero final priority, /and/ have a non-empty due date. This way, tickets with due dates but no final priorities will not accidentally be escalated to zero, and tickets with final priorities but no due date will not be changed (this last condition is arguably unwise, but hey, it's just an example).

[= $RTROOT/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 ]

Developing and testing your TicketSQL expression

1. Use the Query Builder page in the RT web interface to create the query you want, then click on Advanced and copy and paste the TicketSQL code into your crontool command.

2. If you are coding TicketSQL by hand or want to double-check that your TicketSQL expression is correct, use a command like this:

[= $RTROOT/bin/rt-crontool --verbose --search RT::Search::FromSQL --search-arg "YOUR_TICKET_SQL_EXPRESSION_HERE" --action RT::Action::Generic ]

The --verbose flag causes the matching ticket numbers to be displayed, so you can confirm that the right tickets are going to be operated on. The RT::Action::Generic module when used this way operates as a no-op, i.e. it does not update the tickets.