[rt-users] turning off automated e-mails

[Giuseppe Sollazzo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tom,
there's a much simpler way of dealing with it: I guess you want to
have a look at Scrips and Templates.

You can disable some of them. For example, Autoreply is the one
triggered when a ticket is created, Correspond is the one triggered
for any other reply except for a ticket resolution, Resolved is the
resolution.

Possibly, you want to leave just Autoreply and Resolved as active.

Giuseppe

On 15/11/11 15:24, Tom Hansen wrote:
>
> I am new to RT but I have done extensive searching on this and
> have not found what I am looking for. So, apologies if this is an
> FAQ that I have somehow missed.
>
> Basically, I want to set up RT4 so that it will only send e-mails
> upon explicit request. No e-mails on ticket creation, no e-mails
> on status change, no e-mails on adding comments/replies.
>
> I would just like, on every reply/comment, to have an "e-mail
> this" option so that an admin can very simply choose at the time
> of entering a reply or comment, to actually send as an e-mail.
> The DEFAULT would always be to NOT send any e-mails to anyone, and
> even if you choose to update a requestor on a particular reply or
> comment, I don't want that action to "turn on the faucet" for that
> user- I want the default to always be NO E-MAIL.
>
> Why is this? Because I know that my user base would be irritated
> by such e-mails. I know I am when I get automated replies like
> "Your ticket #7546564 has been received. Our next available tech
> will respond." It's like calling an 800 number and getting the
> infamous "your call is very important to us. Please hold and your
> call will be answered in the order it was received."
>
> I ultimately would like the user to receive usually just one
> e-mail when the ticket is closed, consisting of a personal message
> from one of us that also gets recorded in RT. That's it. And even
> that should be optional. Even if the problem had to be bounced
> between two techs, escalated, placed on hold for a day pending
> response from the vendor, before finally being resolved by a third
> tech, and the manager. I just don't want the user going on that
> roller-coaster ride with us unless they want to, and then we would
> only want to manually send out those pieces of information that we
> explicitly choose to share, at the time that we want to share it.
>
> I don't want RT sending out ANY e-mails automatically, EVER.
>
> But I still want the capability to manually choose to send any
> reply/comment from RT to a user if need be. But only on explicit
> manual request from the admin entering the information into RT.
>
> This sounds like such a simple, obvious scenario, yet I find
> support for it nowhere. Must I spend a week learning the internals
> of RT and write my own extension, to just set it so that it will
> only send e-mails manually?
>
>
> For now I have implemented a quick fix to allow me to use RT: I
> inserted an "exit" statement into the top of the Perl code routine
> that sends e-mails -- it was the top recommendation on the wiki --
> and then I went in and, via a custom callback I got from the Wiki,
> suppressed the listing of those numerous "e-mail sent" entries
> that pollute the ticket history. But this solution means that I'm
> forever copying and pasting to and from e-mails to users. Which
> is fine, it's doable. But why does it need to be so hard to just
> turn off automatic e-mailing from RT?
>


- -- 
____________________________________

Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George's, University Of London
Cranmer Terrace
London SW17 0RE

Email: gsollazz at sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOwokzAAoJEAqigArPBfJXjWQH/27Vv8LtD96768Xd4zslR+i4
yqZV/zPSykPq2UOPKYQr6DkgrRPt4lqEfP+aeJ7djAJI8Q98tpSlB0srN6Y5CibI
LpbwsXmvxCTD/qsG57w5A3Yt5mIQnNMJNboS9K3j06T6vbB+Zr1oWQo3Xs1I/xSq
WmBf6Q3h95bLD7IWMpGPjA3nWgv9RjZzNROYznKppl/nVUscmAqkqy3ZrPWtxBZK
9XDaQ9jxCumaAB55GCf4LG+wmqLnR7jLD15WNM9aIVOYZcp/UQdWV86DE8LcFLFx
2zDYkfTAki/UihtEW26sz056tZ1SG4CAsnlUxHciDks/TyA0MaDVXQYqRArCYJA=
=tHem
-----END PGP SIGNATURE-----