[rt-users] Customize Notifications (on correspond send e-mail to all requestors and Ccs)

[Bart]

Hi,

I've managed to turn off the reply feature using the following wiki article:

   - http://requesttracker.wikia.com/wiki/OnWebCorrespond

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.


-- 
Bart

2012/10/10 Thomas Sibley <trs at 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:
> >
> >  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20121023/78d455a0/attachment.htm>