AnyTransactionSource - internal/external correspondence

I’m not sure if I’ve already described our approach to the
Correspond/Create transactions, which differs somewhat from the way
things are handled in standard RT–but I don’t see anything on our web

So here we go:

I’ve created a scrip condition which enables us to treat internal and
external correspondence differently. The basic idea is that you
want to send mail to your requestors and Ccs, but duplicates are the
result when you resend replies sent by these people. (And you can
cause mail loops, too!) To tell internal sources of transactions from
external ones, we look at the originator and check wether he or her
has ModifyTicket rights on the ticket. We keep these rights under
tight control, so this works reasonable well in our environment.

Here’s an excerpt from the file

This condition can be used to obtain better control over the

conditions under which replies are sent to requestors. Transactions

are divided in two categories: those of internal orgin, and those of

external origin. The origin is internal if the originator of a

transaction has got ModifyTicket rights on the ticket, and the

originator is not one of the requestors.

The following ScripConditions are recommended:

| | | applicable

name | execmodule | argument | transtypes


OnCreateExternal | AnyTransactionSource | external | Create

OnCreateInternal | AnyTransactionSource | internal | Create

OnCorrespondExternal | AnyTransactionSource | external | Correspond

OnCorrespondInternal | AnyTransactionSource | internal | Correspond

Now it is possible to use the following scrips:

OnCreateExternal AutoreplyToRequestors Autoreply

OnCreateInternal NotifyRequestorsAndCcs Correspondence

OnCorrespondInternal NotifyRequestorsAndCcs Correspondence

Plus the usual scrips to notify the AdminCCs.

In such a setup, it is possible to create a new ticket and

immediately enter the requestors and they will receive the standard

correspondence messages (and not an autoreply for something they

have never sent). Furthermore, if a requestor replies to a ticket

from a different email account, the reply won’t be sent back to his

requestor account. Not only is this more consistent with user

expectations, but it also reduces the risks of mail loops

considerably. (Consequently, it is recommended to remove the

Reply-To: header generation from Action/ because the Cc:

should now really be honored by those who are sending replies.)

Get it from:

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898