Not sending notifications to users that already received them

Hi, folks.

I’m putting an RT server into production to help handle our support.
I would like to keep it as simple as possible to correspond with users
by e-mail, without using the Web interface, and have RT do the right
thing. (I’m way too addicted to my Emacs…)

One current snag with this is the behavior of the notification scrip
actions. They always send mail to all selected recipients
(Requestors, Ccs, etc) for the ticket, even if the transaction was the
result of sending mail to both RT and those recipients.

I created a set of scrip actions based on RT::Action::Notify that
strip out the mail To and Cc addresses from the list of destinations
for the current mail message. Are patches welcome? =) And if so,
should I send a patch against RT::Action::Notify, or a patch that adds
a bunch more script actions for “Notify Non-Mailed …”? (The former
makes more sense to me, but perhaps not everyone would agree.)

–bert

Hi, folks.

I’m putting an RT server into production to help handle our support.
I would like to keep it as simple as possible to correspond with users
by e-mail, without using the Web interface, and have RT do the right
thing. (I’m way too addicted to my Emacs…)

One current snag with this is the behavior of the notification scrip
actions. They always send mail to all selected recipients
(Requestors, Ccs, etc) for the ticket, even if the transaction was the
result of sending mail to both RT and those recipients.

I created a set of scrip actions based on RT::Action::Notify that
strip out the mail To and Cc addresses from the list of destinations
for the current mail message. Are patches welcome? =) And if so,
should I send a patch against RT::Action::Notify, or a patch that adds
a bunch more script actions for “Notify Non-Mailed …”? (The former
makes more sense to me, but perhaps not everyone would agree.)

Sounds like an excellent idea!
I can’t wait until it makes it into RT tho - would you mind mailing me your
code?
Cheers,
Cerion

P.S. Maybe worth mailing this one rt-devel

On the srface 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. RT 3.2 also
records all out-going e-mails. By not sending to some
users you will not have the positive confirmation that
e-mail was sent to a particular user.

-ToddOn Tue, Aug 03, 2004 at 06:38:28PM +0200, Cerion Armour-Brown wrote:

On Tuesday 03 August 2004 16:14, Albert Dvornik wrote:

Hi, folks.

I’m putting an RT server into production to help handle our support.
I would like to keep it as simple as possible to correspond with users
by e-mail, without using the Web interface, and have RT do the right
thing. (I’m way too addicted to my Emacs…)

One current snag with this is the behavior of the notification scrip
actions. They always send mail to all selected recipients
(Requestors, Ccs, etc) for the ticket, even if the transaction was the
result of sending mail to both RT and those recipients.

I created a set of scrip actions based on RT::Action::Notify that
strip out the mail To and Cc addresses from the list of destinations
for the current mail message. Are patches welcome? =) And if so,
should I send a patch against RT::Action::Notify, or a patch that adds
a bunch more script actions for “Notify Non-Mailed …”? (The former
makes more sense to me, but perhaps not everyone would agree.)

Sounds like an excellent idea!
I can’t wait until it makes it into RT tho - would you mind mailing me your
code?
Cheers,
Cerion

P.S. Maybe worth mailing this one rt-devel


The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com

Todd Chapman rt@chaka.net writes:

On the srface 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.

OK, this is a very good argument for why this shouldn’t be the default
behavior.

I’ve just put this up on the wiki for now:
Request Tracker Wiki

Todd, feel free to add your cautions to the page (I didn’t feel like
blatantly cut+pasting from your e-mail).

RT 3.2 also records all out-going e-mails. By not sending to some
users you will not have the positive confirmation that e-mail was
sent to a particular user.

-Todd

The only truly positive confirmation would be a return receipt from
the user’s mail system, no?

–bert

Todd Chapman rt@chaka.net writes:

On the srface 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.

OK, this is a very good argument for why this shouldn’t be the default
behavior.
Agreed.
Poss to add a transaction regarding removed Cc’s?

I’ve just put this up on the wiki for now:
Request Tracker Wiki
Great!
Cerion

RT 3.2 also records all out-going e-mails. By not sending to some
users you will not have the positive confirmation that e-mail was
sent to a particular user.

The only truly positive confirmation would be a return receipt from
the user’s mail system, no?

That’s confirmation of receipt, not of sending :wink: