[rt-users] turning off automated e-mails

2011-11-17 Thread Sharon . Belliveau
Tom -

When we started using RT (3.6?), we set the template to 'Blank' for all
scrips until we figured out which messages we did want to send.  We then
enabled the On Resolve, Reply to Requestors. Drawback: no silent resolve.

We briefly tried a user-defined scrip for a silent resolve. The scrip was
tied to Custom Field called Reply to Requestors?.  See the RT wiki for
how to implement this:
http://requesttracker.wikia.com/wiki/Silent_Resolve_%28MuteResolve_ReRedux%29

We are moving to RT 4 shortly and plan to enable scrips that will send
email for Reply and Comments.  RT 4 has a 'Recipients' box on top of the
page for updating ticket. This box contains a check list of those whose
role allows them to receive the current Reply or Comment.  One can silently
add comments by unchecking names. After we move to RT 4, we will disable
scrip that sends a reply to requestors when the ticket is resolved. Folks
can post a Reply when resolving at ticket if they'd like to send
information to the Requestor.

Sharon Belliveau
Federal Reserve Board




Subject: Re: [rt-users] turning off automated e-mails
Tom,

Also, you can disable ALL the Global notification scrips and just create
what you want at the Queue level.

The option to select whether you want an email to go out, with the default
being NO, is not there, that I know of. However, if it is really that
important, ask BP what it would cost to modify your version for you.

Kenn
LBNL

On Tue, Nov 15, 2011 at 7:45 AM, Giuseppe Sollazzo
gsoll...@sgul.ac.ukwrote:


 -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?
 






RT

Re: [rt-users] turning off automated e-mails

2011-11-17 Thread k...@rice.edu
On Thu, Nov 17, 2011 at 09:53:49AM -0500, sharon.belliv...@frb.gov wrote:
 Tom -
 
 When we started using RT (3.6?), we set the template to 'Blank' for all
 scrips until we figured out which messages we did want to send.  We then
 enabled the On Resolve, Reply to Requestors. Drawback: no silent resolve.
 
 We briefly tried a user-defined scrip for a silent resolve. The scrip was
 tied to Custom Field called Reply to Requestors?.  See the RT wiki for
 how to implement this:
 http://requesttracker.wikia.com/wiki/Silent_Resolve_%28MuteResolve_ReRedux%29
 
 We are moving to RT 4 shortly and plan to enable scrips that will send
 email for Reply and Comments.  RT 4 has a 'Recipients' box on top of the
 page for updating ticket. This box contains a check list of those whose
 role allows them to receive the current Reply or Comment.  One can silently
 add comments by unchecking names. After we move to RT 4, we will disable
 scrip that sends a reply to requestors when the ticket is resolved. Folks
 can post a Reply when resolving at ticket if they'd like to send
 information to the Requestor.
 
 Sharon Belliveau
 Federal Reserve Board
 

Hi Sharon and Tom,

One approach that we use is to define a custom field called something
like Send Resolve. Then update the resolve scrips to check for that
custom field and if it is set to no, do not send the notice.

Cheers,
Ken

RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011


Re: [rt-users] turning off automated e-mails

2011-11-16 Thread Kenneth Crocker
Tom,

Also, you can disable ALL the Global notification scrips and just create
what you want at the Queue level.

The option to select whether you want an email to go out, with the default
being NO, is not there, that I know of. However, if it is really that
important, ask BP what it would cost to modify your version for you.

Kenn
LBNL

On Tue, Nov 15, 2011 at 7:45 AM, Giuseppe Sollazzo gsoll...@sgul.ac.ukwrote:


 -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: gsoll...@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-

 
 RT Training Sessions (http://bestpractical.com/services/training.html)
 *  Barcelona, Spain  November 28  29, 2011


RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain — November 28  29, 2011

[rt-users] turning off automated e-mails

2011-11-15 Thread Tom Hansen


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?


--
Tom Hansen
Senior Information Processing Consultant
UWM School of Freshwater Sciences
Great Lakes WATER Institute
t...@uwm.edu
www.freshwater.uwm.edu


RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011


Re: [rt-users] turning off automated e-mails

2011-11-15 Thread 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: gsoll...@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-


RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011