Admin: 2 revisions imported

2016-04-06T20:03:14Z

2 revisions imported

New page

== 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.

AnotherConfigurationEscalationExample - Revision history

Admin: 2 revisions imported