Customize Notifications (on correspond send e-mail to all requestors and Ccs)


#1

Hi,

I’m currently trying to modify the default behavior of our RT 4.0.7
installation regarding sending notifications to all requestors/cc’s when
someone corresponds to a ticket.

By default, when you have a ticket and linked a few requestors and cc’s to
that ticket RT will send an e-mail to everyone when someone sends an e-mail
to RT with the ticket ID in the subject.
We\re looking for the ability to disable this feature for a few queue’s.

The problem however is that I’m unable to figure out which scrip I need to
modify to achieve this, I’m guessing between the following scrips but I
keep breaking unwanted things when I disable one of them:

  • On Correspond Notify Other Recipients
  • On Correspond Notify Requestors and Ccs
  • On Comment Notify Other Recipients as Comment

When looking around I found the extension RT::Extension::NotificationMatrix
but it doesn’t really seem to exist on the CPAN pages + installation
instructions aren’t available for installing this plugin from the Git
repository.

In a way this extension would probavbly give us the ability to manage the
notifications for each queue, but installing it doesn’t seem to be that
straight forward + I can’t find any documentation other then the source
code on this extension.
Apart from the nice find, I’m not jumping on the idea of using this
extension when there’s barely any documentation available.

So my main question is how to disable the described notification behavior
when someone sends a reply to a ticket? Which scrip do I disable or edit
for this behavior to change?

Thanks in advance.

Bart


#2

By default, when you have a ticket and linked a few requestors and cc’s
to that ticket RT will send an e-mail to everyone when someone sends an
e-mail to RT with the ticket ID in the subject.
We\re looking for the ability to disable this feature for a few queue’s.

Do you want to disable it only for incoming email to the ticket or all
on replies to the ticket including those from the web?

The problem however is that I’m unable to figure out which scrip I need
to modify to achieve this, I’m guessing between the following scrips but
I keep breaking unwanted things when I disable one of them:

  • On Correspond Notify Other Recipients
  • On Correspond Notify Requestors and Ccs
  • On Comment Notify Other Recipients as Comment

“On Correspond Notify Requestors and Ccs” is the default scrip shipped
with RT which handles the behaviour you described above.

“On Correspond Notify Other Recipients” handles the One-time Cc and
One-time Bcc fields in the web UI and technically may be triggered by
incoming email as well with the headers RT-Send-Cc and RT-Send-Bcc.
Most of the time this scrip only fires on web replies.

“On Comment …” deals only with comments, not replies (correspondence).

When looking around I found the extension
RT::Extension::NotificationMatrix but it doesn’t really seem to exist on
the CPAN pages + installation instructions aren’t available for
installing this plugin from the Git repository.

Apart from the nice find, I’m not jumping on the idea of using this
extension when there’s barely any documentation available.

Your intuition is correct. NotificationMatrix is a nice idea in
concept, but the implementation in the git repo has a few… quirks.
It’s also a) only compatible with 3.8 and b) built upon a subsystem of
RT that’s getting removed in 4.2.

So my main question is how to disable the described notification
behavior when someone sends a reply to a ticket? Which scrip do I
disable or edit for this behavior to change?

If you’re looking to disable ALL redistribution of replies to tickets,
both via email and the web, you can disable the first two scrips you
list above (change their “Stage” to “disabled”).

Since these are global scrips, however, that’ll affect all queues. To
only affect certain queues, you can create an intentionally blank
Correspondence template in each desired queue. (The On Correspond
scrips you mention above use the Correspondence template unless you’ve
changed it to something else.) Queue level templates override global
ones with the same name for tickets in that queue, and blank templates
suppress mail.

Hopefully that helps.

Thomas


#3

Hi Thomas,

Thanks for your reply.

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.

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.
  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)

Bart2012/9/27 Thomas Sibley trs@bestpractical.com

On 09/25/2012 02:28 AM, Bart wrote:

By default, when you have a ticket and linked a few requestors and cc’s
to that ticket RT will send an e-mail to everyone when someone sends an
e-mail to RT with the ticket ID in the subject.
We\re looking for the ability to disable this feature for a few queue’s.

Do you want to disable it only for incoming email to the ticket or all
on replies to the ticket including those from the web?

The problem however is that I’m unable to figure out which scrip I need
to modify to achieve this, I’m guessing between the following scrips but
I keep breaking unwanted things when I disable one of them:

  • On Correspond Notify Other Recipients
  • On Correspond Notify Requestors and Ccs
  • On Comment Notify Other Recipients as Comment

“On Correspond Notify Requestors and Ccs” is the default scrip shipped
with RT which handles the behaviour you described above.

“On Correspond Notify Other Recipients” handles the One-time Cc and
One-time Bcc fields in the web UI and technically may be triggered by
incoming email as well with the headers RT-Send-Cc and RT-Send-Bcc.
Most of the time this scrip only fires on web replies.

“On Comment …” deals only with comments, not replies (correspondence).

When looking around I found the extension
RT::Extension::NotificationMatrix but it doesn’t really seem to exist on
the CPAN pages + installation instructions aren’t available for
installing this plugin from the Git repository.

Apart from the nice find, I’m not jumping on the idea of using this
extension when there’s barely any documentation available.

Your intuition is correct. NotificationMatrix is a nice idea in
concept, but the implementation in the git repo has a few… quirks.
It’s also a) only compatible with 3.8 and b) built upon a subsystem of
RT that’s getting removed in 4.2.

So my main question is how to disable the described notification
behavior when someone sends a reply to a ticket? Which scrip do I
disable or edit for this behavior to change?

If you’re looking to disable ALL redistribution of replies to tickets,
both via email and the web, you can disable the first two scrips you
list above (change their “Stage” to “disabled”).

Since these are global scrips, however, that’ll affect all queues. To
only affect certain queues, you can create an intentionally blank
Correspondence template in each desired queue. (The On Correspond
scrips you mention above use the Correspondence template unless you’ve
changed it to something else.) Queue level templates override global
ones with the same name for tickets in that queue, and blank templates
suppress mail.

Hopefully that helps.

Thomas


Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! http://bestpractical.com/jobs


#4

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.

  1. 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.


#5

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:

  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.

  1. 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


#6

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;

I’m glad to hear you got it working. :slight_smile:

As a heads up for you and other users who may be using the “check for a
Received: header” heuristic, a future 4.0.x release will have an
X-RT-Interface header containing one of the values: Email, Web, Mobile,
or REST. (This is on the not-yet-merged 4.0/interface-in-headers
branch.) The X-RT-Interface header will do away with any potential
ambiguity around how the ticket was created.

Thomas


#7

Hello there

I have the same problem as in the original post by @Bart

We want to be able to send an email to the requestor when providing an answer inside RT-Web. But when a co-worker sends an answer to a ticket, the requestor must not get this email.

We are running RT 4.4.1, is the script above still correct as custom condition?
Or ist there a better solution for this?
Since @Thomas_Sibley mentioned some changes in the header …

Thank you,
best regards,
Joern


#8

We still use the workaround that we implemented in the past.

The headers mentioned by @Thomas_Sibley are new/extra headers, that should be part of RT 4.4.2 by now? Though, I haven’t looked into the new headers, if it isn’t broken… ^_~


#9

Hi Bart,

Is this gonna work when you copy the subject that links to the specific ticket ID like [rt.mydomain.com #01]Sample Email. We sometimes reply via Outlook to a ticket in RT but whenever we copy the subject that links to the ticket, it also sends to the requestor, so we have to disable the notify requestor or unchecked the 'Modify who send a ticket mail" display in People page.

Thanks.

Regards,
Karen


#10

For us it also results in being able to send/forward emails to tickets without resulting a mailing to a requestor/cc. So basically you can send a reply to the requestor via outlook and have your RT mail on the bcc or something like that. It should prevent a second mailing to the requestor from RT. Also, in such a scenario, you could use the RT comment address to register the mail you’ve send outside RT as a comment instead of correspondence.

Do you have a testing environment where you can experiment with these scrips? I’d highly recommend testing scrip changes in such an environment.


#11

Hi Bart,

Thanks for the help. I already tested it and it’s working. :blush:

Regards,
Karen