[rt-users] Custom Scrip that sometimes emails?
Ruslan Zakirov
ruz at bestpractical.com
Mon Jan 16 12:27:34 EST 2012
On Mon, Jan 16, 2012 at 21:14, John Hascall <john at iastate.edu> wrote:
>
>
>> On Mon, Jan 16, 2012 at 19:19, John Hascall <john at iastate.edu> wrote:
>> >> On Mon, Jan 16, 2012 at 07:35, John Hascall <john at 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.
More information about the rt-users
mailing list