The recent discussion on modifying custom fields got me thinking… What
is the difference between using rt and rt-crontool?
Seems that both can do slightly different things and are really different
tools. The name makes it seem like rt-crontool is somehow preferred when
running a scheduled job, but I can’t think of a reason why rt could not be
used in a cron job.
Here’s a script I use to create a linked ticket from an email:
#!/bin/bash
exim helper script for adding an invoice ticket to a work order
subject=$(grep -i ‘^subject:’ $t | sed -e 's/^.*: //')
ticket=$(/opt/rt4/bin/rt create -t ticket set queue=“Water Invoices”
subject=“${subject}” | sed -e s/[^0-9]//g)
parent=$(/opt/rt4/bin/rt ls -i “‘CF.{Work Order No.}’=${LOCAL_PART} and
queue!=‘Water Invoices’” | sed -e s+^./++)
validate $parent here; exit 1 if not found
if [[ -z $parent ]] ; then
echo “Work Order ${LOCAL_PART} not found”
exit 1
fi
exit 1 if multiple tickets found
if [ echo $parent | wc | awk '{print $2}' -gt 1 ] ; then
echo “Multiple tickets with Work Order ${LOCAL_PART} found”
echo "ticket numbers are " echo $parent | sed s+ticket/++g
exit 1
fi
Now link ticket
/opt/rt4/bin/rt link ${ticket} memberof ${parent}
and set custom fields
/opt/rt4/bin/rt edit ticket/${ticket} set ‘CF.{contractor}’=“${contractor}”
/opt/rt4/bin/rt edit ticket/${ticket} set ‘CF.{amount}’=“${amount}”
Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.
The recent discussion on modifying custom fields got me thinking… What
is the difference between using rt and rt-crontool?
bin/rt is a general purpose tool that uses the REST interface
rt-crontool is intended to glue together existing
RT::Search/RT::Condition/RT::Action/RT::Templates.
For example, I could do your bin/rt script as a CreateTickets action
with a custom Template.
If the search, condition and action you want already exist (such as
bumping priority on tickets after 5 days without an owner) then
rt-crontool is going to just work with a lot less code than recreating
that in bin/rt.
Also, looping over hundreds of tickets should be faster in rt-crontool
rather than bin/rt because it uses the API rather than making tons of
HTTP requests.
I believe that the real difference is that the RT tool allows you to
actually create tickets and the RT-CronTool only has the ability to edit
them.
Other then that I wouldn’t know much about the differences (except for the
syntax of course).
As for using the RT tool for cron, I can’t see a reason for not using it in
cron. (both RT tool and RT-CronTool have their use I guess)
We’re using the RT tool in cron for creating periodic tickets (example
below):
#!/bin/bash
/opt/rt4/bin/rt create -t ticket
set subject=‘A ticket subject, something snappy’
set owner=who.should.be.the.owner@example.com
set requestor=who.should.be.the.requestor@example.com
set queue=‘Queue Name’
set text=‘More detailed text regarding the periodic action.’
set CF-‘Ticket Type’=‘Change’
set CF-‘Ticket Priority’=‘4’
set CF-‘Item A’=‘Server’
set CF-‘Item B’=‘Admin’
set CF-‘Item C’=‘Update’
It’s nothing fancy but it’s a straight forward way for creating tickets
– BartOp 23 november 2011 20:06 schreef Yan Seiner yan@seiner.com het volgende:
The recent discussion on modifying custom fields got me thinking… What
is the difference between using rt and rt-crontool?
Seems that both can do slightly different things and are really different
tools. The name makes it seem like rt-crontool is somehow preferred when
running a scheduled job, but I can’t think of a reason why rt could not be
used in a cron job.
Here’s a script I use to create a linked ticket from an email:
#!/bin/bash
exim helper script for adding an invoice ticket to a work order
subject=$(grep -i ‘^subject:’ $t | sed -e 's/^.*: //')
ticket=$(/opt/rt4/bin/rt create -t ticket set queue=“Water Invoices”
subject=“${subject}” | sed -e s/[^0-9]//g)
parent=$(/opt/rt4/bin/rt ls -i “‘CF.{Work Order No.}’=${LOCAL_PART} and
queue!=‘Water Invoices’” | sed -e s+^./++)
validate $parent here; exit 1 if not found
if [[ -z $parent ]] ; then
echo “Work Order ${LOCAL_PART} not found”
exit 1
fi
exit 1 if multiple tickets found
if [ echo $parent | wc | awk '{print $2}' -gt 1 ] ; then
echo “Multiple tickets with Work Order ${LOCAL_PART} found”
echo "ticket numbers are " echo $parent | sed s+ticket/++g
exit 1
fi
Now link ticket
/opt/rt4/bin/rt link ${ticket} memberof ${parent}
and set custom fields
/opt/rt4/bin/rt edit ticket/${ticket} set ‘CF.{contractor}’=“${contractor}”
/opt/rt4/bin/rt edit ticket/${ticket} set ‘CF.{amount}’=“${amount}”
–
Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.
Op 23 november 2011 20:29 schreef Kevin Falcone falcone@bestpractical.comhet volgende:> On Wed, Nov 23, 2011 at 11:06:12AM -0800, Yan Seiner wrote:
The recent discussion on modifying custom fields got me thinking… What
is the difference between using rt and rt-crontool?
bin/rt is a general purpose tool that uses the REST interface
rt-crontool is intended to glue together existing
RT::Search/RT::Condition/RT::Action/RT::Templates.
For example, I could do your bin/rt script as a CreateTickets action
with a custom Template.
If the search, condition and action you want already exist (such as
bumping priority on tickets after 5 days without an owner) then
rt-crontool is going to just work with a lot less code than recreating
that in bin/rt.
Also, looping over hundreds of tickets should be faster in rt-crontool
rather than bin/rt because it uses the API rather than making tons of
HTTP requests.
-kevin
Seems that both can do slightly different things and are really different
tools. The name makes it seem like rt-crontool is somehow preferred when
running a scheduled job, but I can’t think of a reason why rt could not
be
used in a cron job.
Here’s a script I use to create a linked ticket from an email:
#!/bin/bash
exim helper script for adding an invoice ticket to a work order
subject=$(grep -i ‘^subject:’ $t | sed -e 's/^.*: //')
ticket=$(/opt/rt4/bin/rt create -t ticket set queue=“Water Invoices”
subject=“${subject}” | sed -e s/[^0-9]//g)
parent=$(/opt/rt4/bin/rt ls -i “‘CF.{Work Order No.}’=${LOCAL_PART} and
queue!=‘Water Invoices’” | sed -e s+^./++)
validate $parent here; exit 1 if not found
if [[ -z $parent ]] ; then
echo “Work Order ${LOCAL_PART} not found”
exit 1
fi
exit 1 if multiple tickets found
if [ echo $parent | wc | awk '{print $2}' -gt 1 ] ; then
echo “Multiple tickets with Work Order ${LOCAL_PART} found”
echo "ticket numbers are " echo $parent | sed s+ticket/++g
exit 1
fi
Now link ticket
/opt/rt4/bin/rt link ${ticket} memberof ${parent}
and set custom fields
/opt/rt4/bin/rt edit ticket/${ticket} set
‘CF.{contractor}’=“${contractor}”
/opt/rt4/bin/rt edit ticket/${ticket} set ‘CF.{amount}’=“${amount}”
–
Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.
