RT Global Scrip issue

Hey guys,

I am running RT 3.8.8 and I am running into an issue with how scrips are handling transactions. In order to only selectively run certain global scrips on queues, I have enabled the plugin RT-Extension-QueueDeactivatedScrips.

I get all my systems IT support email coming pre-filtered into a queue called IT. The first scrip that I call searches for all email headers for a spam tag. If that spam tag is found, that ticket is marked to go into the SPAM queue. Every global scrip is disabled in the SPAM queue and the ticket is resolved automatically.

However since the initial email came into the IT queue, it still sees that transaction and applies the rest of global scrips to that ticket. One of the global scrips emails all the sysadmin staff resulting in spam tickets being delivered to our inboxes.

I will be happy to provide transaction log details if needed.

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 ?

Is there a workaround around this ?

John.

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.

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.