Hi,
I’ve managed to turn off the reply feature using the following wiki article:
All I had to do was change the condition of the scrip “On Correspond Notify
Requestors and Ccs” to “User defined” and enter this custom condition:
my $trans = $self->TransactionObj;
return 0 unless $trans->Type eq “Correspond”;
my $msgattr = $trans->Message->First;
return 1 unless $msgattr;
return 0 if $msgattr->GetHeader(‘Received’);
return 1;
After that all functionality remained working (incoming mails are
registered, people receive an auto-reply, manual mails can be send, etc.)
but without the feature where “someone” sends a mail to RT with “a” ticket
ID in it which would trigger this scrip to send that mail to all requestors
and ccs linked to that specific ticket.
I’ve edited the global script, basically disabling this by default for all
queue’s. We’ll enable this feature again on specific queue’s when our users
require it.
Thanks for the replies so far, thanks to them I was able to narrow down the
feature towards one specific scrip which made turning off the feature
relatively easy.
Bart2012/10/10 Thomas Sibley trs@bestpractical.com
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:
- 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.
- Keep the ability to actually send e-mails to requestors or to
one-time cc’s.
- 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.
- 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! Careers — Best Practical Solutions
