NotifyNonRecipients

Overview

The notification scrip actions in RT3 (at least up to RT 3.2.1) always send mail to all selected recipients (Requestors, Ccs, etc) for the ticket. This will be true even if the transaction was the result of sending mail to both RT and those recipients.

There are cases where this mail duplication is a good idea, but in some environments it is undesirable. If you don't like the default behavior, you can install some alternate scrip actions that will fix this. If a transaction is caused by an e-mail message, the original mail's To and Cc headers (and From, if $RT::NotifyActor isn't set) will be removed from the list of recipients to which RT will send mail.

How to set this up in RT3:

/(This has so far only been tested with RT 3.2.1.)/

Download NotifyNonRecipients.tar.gz, uncompress and untar. Copy the .pm files into the corresponding places in your RT3 local customizations area:

/path/to/rt3/local/lib/RT/Action/NotifyNonRecipients.pm
/path/to/rt3/local/lib/RT/Action/NotifyNonRecipientsAsComment.pm

Tell RT about the new scrip actions by running

/path/to/rt3/sbin/rt-setup-database --action insert \
   --datafile /path/to/NotifyNonRecipients.insert

This should cause your RT3 installation to support several new "Notify Non-Mailed ..." scrip actions. In the GUI, just go to the relevant scrip configuration page and select the new option from the pull-down.

Note

On the surface this seems like a good idea, but there are issues to consider. What RT sends out is based on the configured templates. By not sending to some users who are already Cc'd you risk that different users see similar but probably different messages.

Another note:

We've been using this for several years, and just found a strange/subtle bug. The perl Action compiles a list of addresses to email, and then sets a flag for addresses which already got the email (from the To and CC list), to exclude them from RT's lists. However, it uses grep and a hash for this, so the addresses have to match exactly. In particular, "user@TLA.Domain.com" does not match "user@tla.domain.com". So if the email address in the RT user database uses capital letters, you never get a match, even if the email is sent with the same capitalization, because the address in the email gets lowercased before the matching is done. So the user gets two emails (one direct from sender, and one from RT). This is probably a pretty rare problem.