[rt-users] RT Global Scrip issue

[Thomas Sibley]

Read below for more details, but the simplest approach: keep your spam
filtering outside of RT.  It's already tagged spam/not-spam outside RT,
so also direct it to a blockhole or the Spam queue directly from outside
RT.  procmail is good for this sort of header matching.  You just call
rt-mailgate with --queue Spam.

On 04/25/2013 07:42 AM, Sibi John wrote:
> Why does RT not stop processing other global scrips in the IT queue,
> once it has been assigned a different queue ? How do you deal with
> something like this ? Is this a bug that has been fixed in future
> versions ?

Scrips run after tickets are created and transactions are committed to
the database.  Changing ticket data in a scrip may fire more scrips, but
scrips run independently of each other.  They trigger based on the
transactions that happen and always trigger if a transaction meets their
condition.  Aborting all of scrips when a queue change happens gives you
less flexibility in terms of all the workflows you can implement.

So, not a bug, intended behaviour.

> Is there a workaround around this ?

You could make all the other scrips check if the ticket is still in the
queue it was created in, but that's potentially a lot of work.

The typical approach when there's a dispatch/routing queue of some sort
is to separate it completely from working queues and have scrips move
*every* ticket that comes in to somewhere else.

In your case, you'd have an "Incoming" queue (named whatever you like)
which either moves tickets to IT or Spam.  You'll need to rejigger your
scrips a little in IT to trigger on tickets moving into it as well as
created directly in it.