Owner Correspondence Scrip

We would like to setup our system so that the owner isn’t notified of every
transaction, but is notified of any comments any Ccs make or any requestor
correspondence.

I’ve set the following scrips:
OnComment NotifyOwner with template AdminComment
OnCorrespond NotifyOwner with template AdminCorrespondence

I also have the same scrips set for NotifyAdminCcs, and those work just
fine. However, ticket owners are not getting these emails when coming from
an AdminCc or Requestors (this isn’t the issue of the person doing the
comment/correspondence in RT not getting an email about it).

I checked the mail log for this and it doesn’t appear to be off (sendmail
sends it to our Exchange mailserver, so there could be something there, but
I can’t imagine what since all other emails come through).

log example:

May 8 16:57:39 vid sendmail[17510]: g48NvdE17508: to=spedersen@company.com,
ctladdr=apache(48/48), delay=00:00:00, xdelay=00:00:00, mailer=esmtp,
pri=138641, relay=mailserver.company.com. [10.1.1.1], dsn=2.0.0, stat=Sent
( rt-285-1550.12.9248290274241@company Queued mail for delivery)

Does anyone have any thoughts about what I’m missing here?

Thanks,
-shannon pedersen

I also have the same scrips set for NotifyAdminCcs, and those work just
fine. However, ticket owners are not getting these emails when coming from
an AdminCc or Requestors (this isn’t the issue of the person doing the
comment/correspondence in RT not getting an email about it).

I’m having a similar problem. I have only the default global scrips
defined (I may have removed some), which are:

OnCreate AutoreplyToRequestors with template Autoreply OnCreate
NotifyAdminCcs with template Transaction OnCorrespond
NotifyAllWatchers with template Correspondence OnComment
NotifyAdminCcsAsComment with template AdminComment OnComment
NotifyOtherRecipientsAsComment with template Correspondence
OnCorrespond NotifyOtherRecipients with template Correspondence

Whenever anyone updates the ticket, all of the AdminCC’s get the
update, except the person who made the update doesn’t. It strikes me
that the “NotifyAdminCcs with template Transaction OnCorrespond”
should be notifying the person who updated the ticket (provided of
course they are a member of AdminCcs, which in my case is true).

Thoughts?

Derek Martin
Lead Network Engineer
ddm@skillsoft.com
(603)324-3000 x516

Whenever anyone updates the ticket, all of the AdminCC’s get the
update, except the person who made the update doesn’t. It strikes me
that the “NotifyAdminCcs with template Transaction OnCorrespond”
should be notifying the person who updated the ticket (provided of
course they are a member of AdminCcs, which in my case is true).

Yours is working as intended - RT doesn’t notify the person who made the
update by email, because the person doing the update should know that they
did it (and therefore doesn’t need notification).

See http://fsck.com/rtfm/article.html?id=5#73

-shannon pedersen

At 11:38 Uhr -0400 9.5.2002, Derek D. Martin wrote:

Whenever anyone updates the ticket, all of the AdminCC’s get the
update, except the person who made the update doesn’t. It strikes me
that the “NotifyAdminCcs with template Transaction OnCorrespond”
should be notifying the person who updated the ticket (provided of
course they are a member of AdminCcs, which in my case is true).

< http://fsck.com/rtfm/article.html?id=5#73 >

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>

log example:

May 8 16:57:39 vid sendmail[17510]: g48NvdE17508: to=spedersen@company.com,
ctladdr=apache(48/48), delay=00:00:00, xdelay=00:00:00, mailer=esmtp,
pri=138641, relay=mailserver.company.com. [10.1.1.1], dsn=2.0.0, stat=Sent
( rt-285-1550.12.9248290274241@company Queued mail for delivery)
^^^^^^^^^^^^^^^^^^^^^^^^

Does anyone have any thoughts about what I’m missing here?

Betcha it’s still in the queue.

-Robin

Robin Powell's Old Home Page BTW, I’m male, honest.
le datni cu djica le nu zifre .iku’i .oi le so’e datni cu to’e te pilno
je xlali – RLP http://www.lojban.org/

Betcha it’s still in the queue.

-Robin

You were right - it came through later on that evening.

Thanks!
-shannon

At 11:38 Uhr -0400 9.5.2002, Derek D. Martin wrote:

Whenever anyone updates the ticket, all of the AdminCC’s get the
update, except the person who made the update doesn’t.

< http://fsck.com/rtfm/article.html?id=5#73 >

Are you taking into account that RT should never
mail the person performing the action? RT tries to
be smart about this. 

Ok, but, I guess my point is I want to receive those e-mails. So
who gets to decide what behavior is smart? :slight_smile:

This is especially useful while trying to configure who gets notified
when, to verify that everything is working as expected. As it stands
now, I have to keep tracking people down to ask if they are or are not
getting messages… not very efficient. It makes making adjustments
to notifications a very slow process.

Is there any way to configure RT to do this (preferably without
hacking the code)? This strikes me as a good candidate for a
configuration setting, if one does not already exist…

While I’m on the topic, is there any plans to make anything
configurable, i.e. controllable by user preferences (i.e. on a
user-by-user basis)? It seems that currently the only thing that’s in
preferences now is user’s password and mail signature. It would be
great to be able to specify a particular font, color scheme, feilds
that are shown in a search query (priority of a ticket is notably
absent from our queries), etc.

If the answer is no, I might be inclined to try to hack some of this
stuff together. Unfortunately it wouldn’t be for a while, as right
now I’m pretty well swamped with work to do.

Thanks for all your help thusfar!

Derek Martin
Lead Network Engineer
ddm@skillsoft.com
(603)324-3000 x516

< http://fsck.com/rtfm/article.html?id=5#73 >

Are you taking into account that RT should never
mail the person performing the action? RT tries to
be smart about this. 

Ok, but, I guess my point is I want to receive those e-mails. So
who gets to decide what behavior is smart? :slight_smile:

This is especially useful while trying to configure who gets notified
when, to verify that everything is working as expected.

Also, we don’t let the users use the web interface. Another reason
allowing senders to receive their own updates is useful is so the
requestor knows their updates got into the system. If they don’t
receive a copy of the update, and the tech assigned to the problem
drops the ball, they really have no way of knowing whether or not
their update even made it into the system.

Am I the only one that cares about this?

Derek Martin
Lead Network Engineer
ddm@skillsoft.com
(603)324-3000 x516

< http://fsck.com/rtfm/article.html?id=5#73 >

Are you taking into account that RT should never
mail the person performing the action? RT tries to
be smart about this. 

Ok, but, I guess my point is I want to receive those e-mails. So
who gets to decide what behavior is smart? :slight_smile:

This is especially useful while trying to configure who gets notified
when, to verify that everything is working as expected.

Also, we don’t let the users use the web interface. Another reason
allowing senders to receive their own updates is useful is so the
requestor knows their updates got into the system. If they don’t
receive a copy of the update, and the tech assigned to the problem
drops the ball, they really have no way of knowing whether or not
their update even made it into the system.

Am I the only one that cares about this?

No, but I think you’re the only one who cares as much as you do.

I think you’re gonna have to go into the code.

Sorry.

-Robin

Robin Powell's Old Home Page BTW, I’m male, honest.
le datni cu djica le nu zifre .iku’i .oi le so’e datni cu to’e te pilno
je xlali – RLP http://www.lojban.org/

Am I the only one that cares about this?

No, but I think you’re the only one who cares as much as you do.

I think you’re gonna have to go into the code.

Ucky. It’s not that I mind digging in the code. I just don’t have
the time. :frowning:

Oh well…

Derek Martin
Lead Network Engineer
ddm@skillsoft.com
(603)324-3000 x516

At 11:29 Uhr -0400 17.5.2002, Derek D. Martin wrote:

If they don’t
receive a copy of the update, and the tech assigned to the problem
drops the ball, they really have no way of knowing whether or not
their update even made it into the system.

I think it’s reasonable to assume that the update made it into the
system unless one receives a failure notification - that’s the way
e-mail works (and paper mail too).
Personally, I’d be rather annoyed if I received an auto-response for
each update.

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>

At 11:29 Uhr -0400 17.5.2002, Derek D. Martin wrote:

If they don’t
receive a copy of the update, and the tech assigned to the problem
drops the ball, they really have no way of knowing whether or not
their update even made it into the system.

I think it’s reasonable to assume that the update made it into the
system unless one receives a failure notification - that’s the way
e-mail works (and paper mail too).

One has to wonder if you’ve ever managed e-mail for a large company…
Misconfigurations often cause mail to vanish into thin air. Mail
spools filling up could cause this also. People make mistakes; these
things happen. Additionally, if there were a problem with the
mailgate program, but that problem did not cause the mailgate program
to exit with a non-zero exit status, you would not receive a failure
notification.

There are lots of reasons why mail might not make it into the system,
but no failure notification gets generated. Your assumption is
definitely not reasonable. It would only be reasonable if the mail
system you’re using could be 100% guaranteed not to ever fail, and the
mail-gate program was guaranteed to be 100% flawless. Obviously,
assuming either of these conditions would be foolish.

Personally, I’d be rather annoyed if I received an auto-response for
each update.

Which is very much why I suggested a configurable option.

Derek Martin
Lead Network Engineer
ddm@skillsoft.com
(603)324-3000 x516

Personally, I’d be rather annoyed if I received an auto-response for
each update.

Which is very much why I suggested a configurable option.

Ideally, what I’d like to see is an option to configure this on a
per-user basis; i.e. each user could set this option in their
preferences or somewhere. A coworker (the manager of our equivalent
of a helpdesk) was also looking for this option, while we were getting
things set up. Ordinarily, he’s fine with not receiving such mail;
but as the person responsible for the RT system, I still want to get
them all the time, so that if I’m NOT receiving them, I know there’s a
problem. Most users probably won’t want to get them, ordinarily.

Derek Martin
Lead Network Engineer
ddm@skillsoft.com
(603)324-3000 x516

Am I the only one that cares about this?

No, but I think you’re the only one who cares as much as you do.

I think you’re gonna have to go into the code.

Ucky. It’s not that I mind digging in the code. I just don’t have
the time. :frowning:

http://www.amsterdamned.org/~bc/rt/BC_SendEmail.pm

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Am I the only one that cares about this?

No, but I think you’re the only one who cares as much as you do.

I think you’re gonna have to go into the code.

Ucky. It’s not that I mind digging in the code. I just don’t have
the time. :frowning:

http://www.amsterdamned.org/~bc/rt/BC_SendEmail.pm

And as Derek has pointed out in private mail, I’m being unnecessarily
obscure :wink:

Attached is BC_SendEmail, BC_Notify.pm and a script to insert a new
ScripAction into the database called ‘BC_NotifyAdminCcs’. Note that I can
only warrent that BC_SendEmail works with sendmailpipe as the MailCommand
in config.pm .

BC_Notify checks for a config.pm frob named ‘SendBackToOriginator’, where
a value of ‘0’ gives the RT default behaviour, and a value of ‘1’ gives
the requested behaviour (if you use BC_NotifyAdminCcs below).

To use, copy BC_SendEmail.pm and BC_Notify.pm into your lib/RT/Action
directory. Change the ‘use lib’ lines in BC_NotifyAdminCcs.pl to reflect
your own installation and run it to add a ScripAction to your database
named ‘BC_NotifyAdminCcs’.

( what, you ran it without checking it? sheesh )

Then, you can go through the WebUI and replace the Scrip for your queue
reading:

OnCorrespond NotifyAdminCcs with Template Correspondence

and
OnCreate NotifyAdminCcs with Template Correspondence

with

OnCorrespond BC_NotifyAdminCcs with template OrigCorrespondence

and
OnCreate BC_NotifyAdminCcs with template OrigCorrespondence

Note that you will need to create the template named ‘OrigCorrespondence’
first. Mine reads somewhat like:

{ $Transaction->Message->First->NiceHeaders() }

{ $Transaction->Content() }
{ my $have_first = 0; my $retval= undef; my $Attachments =
$Transaction->Attachments; while( my $Attachment = $Attachments->Next ){
next if( $Attachment->id == $Transaction->Message->First->id); if(
$Attachment->Content eq $Transaction->Content ){ $have_first = 1 if(
$have_first == 0 ); next if( $have_first <= 1 ); } $retval = “\nURLs to
Attached parts:\n” if( ! defined( $retval ) ); $retval .= " " .
$RT::WebURL . “Ticket/Attachment/” . $Transaction->id . “/” .
$Attachment->id . “\n”; } $retval; }

This results in mails like:Date: Tue, 21 May 2002 21:24:10 +0200 (CEST)
From: Bruce Campbell bruce_campbell@ripe.net
Reply-To: myqueue@ripe.net
To: myqueue@ripe.net
Subject: [ripe.net #46104] testing attachments

some text

URLs to Attached parts:
   http://rt2.ripe.net/Ticket/Attachment/176966/131187

( The last two lines only appear if an attachment was present )

Even if I send it to the queue (wait, I just did :wink: ), I get it back as
part of being an AdminCc on that queue. Other aspects is that I see the
original email address

If you like, you could change the insert script to be other than a
replacement for NotifyAdminCcs, however I personally haven’t done that (we
present a certain interface to the outside, and easily exposing our direct
email addresses isn’t included), but it should work.

Hopefully all of the above helps, and I’m heading home :wink:

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

BC_Notify.pm (2.63 KB)

BC_SendEmail.pm (21.2 KB)

insert_action_BC_NotifyAdminCcs.pl (1.47 KB)