On 09/27/2012 02:36 AM, Bart wrote: > When I disable those scrips I get the following effect: > > * First off, the behavior I want to disable is disabled. > * But, the autoreply scrip doesn't work anymore. > * And, any type of outgoing mail stops working. > > RT simply registers the correspondence when you send a reply but > doesn't record outgoing mail.
That implies you're disabling the wrong scrips or something seriously funny is going on with your RT instance. The scrips you listed and I described are not related to the Autoreply scrip. > I guess what I want to achieve is the following: > > 1. Leave the autoreply upon ticket creating in tact, we want to keep > the ability to send requestors a default mail with their ticket ID + > a small note that we're working on it and that we've received the > mail correctly. > 2. Keep the ability to actually send e-mails to requestors or to > one-time cc's. > 3. But disable the feature where an incoming mail for a ticket triggers > something which sends an e-mail to all requestors/cc's. This > specific feature is something that we'd want to disable for all > queue's, but when we manually send an e-mail from RT to one or more > people then the mail has to go to those people that we've selected > during creating the correspondence. Disabling "On Correspond Notify Requestors and Ccs" will disable all ticket replies (via mail or the web) from going to Requestors and Ccs. It won't disable the "One-time" fields however, and you could use those without any further customization. Note that this would be somewhat of a pain to have to fill in all the requestors' and ccs' addresses whenever you want to actually reply to a ticket. > 4. Also, other scrips that send mails when someone sets you as an > owner, etc. should also keep working. Just the feature of point 3 > which is triggered upon receiving an e-mail is what we want to disable. > > I'm assuming then that I'd have to modify the behavior of these scrips > so that they only trigger when sent from RT itself. I'm assuming this > means that I'll have to write a custom condition for these scrips, what > would be the best way to do this? I'd probably need to get the original > condition and then modify it, but where do I find this? (and where to start) Yep, custom conditions for the one or two scrips which handle this are your best option for distinguishing between incoming mail and the web being the trigger. You'd want to start with an on disk condition that gets a pointer inserted into the database so it shows up in the Scrip action dropdown. This lets you re-use RT's core conditions by subclassing them and writing your own condition check. There's a branch in flight (not yet merged to 4.0-trunk) which adds an X-RT-Interface header that would make your condition check slightly simpler (rather than a variety of heuristics, you'd just check the header). It's called 4.0/interface-in-headers. -------- Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs