[rt-users] Custom Scrip that sometimes emails?

[Ruslan Zakirov]

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.