On Mon, Jan 16, 2012 at 21:14, John Hascall <j...@iastate.edu> wrote: > > >> 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?
Close and will work, but I don't understand why you need special custom field for that. Probably I just lack information about what your parser does with ticket after parsing. > 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? I don't see why you need to sub-class any of RT's actions in this case. > Possible? Pointers on how? Use file based actions and just inherit from a module you want to sub-class. You have to register your module in DB (see wiki). Also, actions and conditions based on files can use argument for configuration. > > > > Many thanks, > John -- Best regards, Ruslan. -------- RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012