> On Mon, Jan 16, 2012 at 19:19, John Hascall <j...@iastate.edu> wrote: > >> On Mon, Jan 16, 2012 at 07:35, John Hascall <j...@iastate.edu> wrote: > >> > I have a custom scrip that does quite a lot of parsing of > >> > the content of an incoming email during ticket creation. > >> > > >> > Now I've been asked that under certain circumstances, > >> > determined by what it finds/doesn't find in the email, > >> > this scrip also send an email (to the requestor as > >> > well as possibly to an email address found in the > >> > message). > > > >> Use second scrip that emails with Notify* actions. Probably your > >> parser also updates ticket with info it found, so you can create > >> condition that finds required situation. > > > > How do I insure that the two scrips execute in the correct order? > > I think in 3.8.1 we already order scrips by description, may be it's > by id. However, you don't need it. Changes from a scrip fire new > scrips. In second scrip you check that particular field was set by > transaction, check new and old values, check other required fields and > decide whether fire or not notification action. > > Advantage of this is that notification is fired even when people > through UI changed ticket in similar way as your parser.
So, just to be sure I understand this correctly. The existing scrip, upon finding that the email is required, sets the value of a custom field (say, email = "needed") This setting of a custom field will trigger RT to run through the list of scrips again. The condition of the new, (emailing), scrip is based on the custom field value (email=="needed"), so it is triggered on this run through. This scrip, after emailing, should, I would guess, then update the CF (say, email = "sent"). Correct? I am guessing that there is some way to not reinvent the wheel and use the abilities of an exist action, perhaps by being a subclass of it? Possible? Pointers on how? Many thanks, John -------- RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012