NoReplyAddress - Revision history

Bparish at 16:52, 13 February 2017

2017-02-13T16:52:31Z

← Older revision		Revision as of 12:52, 13 February 2017
Line 1:		Line 1:
			Many thanks to Best Practical for their help on this one!!!!

	The intent of this is to create a new email address for RT that allows you to email ~~Replies to~~ a ticket, but not ~~pester the Requestor with~~ emails about it.		The intent of this is to create a new email address for RT that allows you to email comments into a ticket that the Requestor(s) can see in the Web UI, but they will not receive emails about it.

	The use-cases of this might be:		The use-cases of this might be:

	1) You just got off the phone with the ticket Requestor. You are updating the ticket with a copy of what you just told them on the phone. Therefore, there is no need to hassle them with an email copy of it. Normally, you might submit this as a Comment in RT so updates the ticket but does not send email to them. However, if you choose this method the Requestor will not (by default) see that Comment in the ticket. For them to see it, it must be of type: Reply (aka Correspondence).		1) You just got off the phone with the ticket Requestor. You are updating the ticket with a copy of what you just told them on the phone. Therefore, there is no need to hassle them with an email copy of it. Normally, you might submit this as a Comment in RT so updates the ticket but does not send email to them. However, if you choose this method the Requestor will not (by default) see that Comment in the ticket. For them to see it, it must be of type: Reply (aka Correspondence).
	2) You are sending an email to the Requestor outside of RT because you want to manage what content goes into the ticket (i.e. if they hit the Reply button it comes back to you, not into RT)~~, or because the~~ recipient of the email you are sending is not part of the ticket.
	3) Any other time you want the Requestor(s) to be able to see your comments within the ticket but don't want to trouble them with email copies of those comments.		2) You are sending an email to the Requestor directly (outside of RT) because you want to manage what content goes into the ticket (i.e. if they hit the Reply button it comes back to you, not into RT).

			3) The recipient of the email you are sending is not part of the ticket. You don't want to hide the email comment from the Requestors, but don't want to hassle them with emails about it.

			4) Any other time you want the Requestor(s) to be able to see your comments within the ticket but don't want to trouble them with email copies of those comments.

	Please note that AdminCcs will still receive an email about this transaction, we are only suppressing email to the Requestor(s).		Please note that AdminCcs will still receive an email about this transaction, we are only suppressing email to the Requestor(s).

Bparish at 16:47, 13 February 2017

2017-02-13T16:47:06Z

← Older revision		Revision as of 12:47, 13 February 2017
Line 13:		Line 13:

	First create a new RT email address. You can call it whatever you like, I use "noreply" in my environment. Here is an example line in /etc/aliases:		First create a new RT email address. You can call it whatever you like, I use "noreply" in my environment. Here is an example line in /etc/aliases:
			''noreply: "\|/opt/rt4/bin/rt-mailgate --queue General --action correspond --url http://rt.example.com/"''
	''noreply: "\|/opt/rt4/bin/rt-mailgate --queue General --action correspond --url http://rt.example.com/"''



Line 23:		Line 21:
	''if ($address =~ m/noreply/) {''		''if ($address =~ m/noreply/) {''

	<~~nowiki~~>		<pre>

	# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF		# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF
Line 105:		Line 103:
	return 1;		return 1;

	</~~nowiki~~>		</pre>

Bparish at 16:44, 13 February 2017

2017-02-13T16:44:22Z

← Older revision		Revision as of 12:44, 13 February 2017
Line 24:		Line 24:

	<nowiki>		<nowiki>
	~~<pre>~~

	# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF		# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF
Line 106:		Line 105:
	return 1;		return 1;

	~~</pre>~~
	</nowiki>		</nowiki>

Bparish at 16:43, 13 February 2017

2017-02-13T16:43:51Z

← Older revision		Revision as of 12:43, 13 February 2017
Line 4:		Line 4:
	The use-cases of this might be:		The use-cases of this might be:

	# You just got off the phone with the ticket Requestor. You are updating the ticket with a copy of what you just told them on the phone. Therefore, there is no need to hassle them with an email copy of it. Normally, you might submit this as a Comment in RT so updates the ticket but does not send email to them. However, if you choose this method the Requestor will not (by default) see that Comment in the ticket. For them to see it, it must be of type: Reply (aka Correspondence).		1) You just got off the phone with the ticket Requestor. You are updating the ticket with a copy of what you just told them on the phone. Therefore, there is no need to hassle them with an email copy of it. Normally, you might submit this as a Comment in RT so updates the ticket but does not send email to them. However, if you choose this method the Requestor will not (by default) see that Comment in the ticket. For them to see it, it must be of type: Reply (aka Correspondence).
	# You are sending an email to the Requestor outside of RT because you want to manage what content goes into the ticket (i.e. if they hit the Reply button it comes back to you, not into RT), or because the recipient of the email you are sending is not part of the ticket.		2) You are sending an email to the Requestor outside of RT because you want to manage what content goes into the ticket (i.e. if they hit the Reply button it comes back to you, not into RT), or because the recipient of the email you are sending is not part of the ticket.
	# Any other time you want the Requestor(s) to be able to see your comments within the ticket but don't want to trouble them with email copies of those comments.		3) Any other time you want the Requestor(s) to be able to see your comments within the ticket but don't want to trouble them with email copies of those comments.

	Please note that AdminCcs will still receive an email about this transaction, we are only suppressing email to the Requestor(s).		Please note that AdminCcs will still receive an email about this transaction, we are only suppressing email to the Requestor(s).
Line 23:		Line 23:
	''if ($address =~ m/noreply/) {''		''if ($address =~ m/noreply/) {''

			<nowiki>
			<pre>

	# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF		# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF
Line 103:		Line 105:

	return 1;		return 1;

			</pre>
			</nowiki>

Bparish: Insert Replies into an RT ticket via email, but suppress notifying Requestors of it

2017-02-13T16:38:49Z

Insert Replies into an RT ticket via email, but suppress notifying Requestors of it

New page

The intent of this is to create a new email address for RT that allows you to email Replies to a ticket, but not pester the Requestor with emails about it.

The use-cases of this might be:

# You just got off the phone with the ticket Requestor. You are updating the ticket with a copy of what you just told them on the phone. Therefore, there is no need to hassle them with an email copy of it. Normally, you might submit this as a Comment in RT so updates the ticket but does not send email to them. However, if you choose this method the Requestor will not (by default) see that Comment in the ticket. For them to see it, it must be of type: Reply (aka Correspondence).
# You are sending an email to the Requestor outside of RT because you want to manage what content goes into the ticket (i.e. if they hit the Reply button it comes back to you, not into RT), or because the recipient of the email you are sending is not part of the ticket.
# Any other time you want the Requestor(s) to be able to see your comments within the ticket but don't want to trouble them with email copies of those comments.

Please note that AdminCcs will still receive an email about this transaction, we are only suppressing email to the Requestor(s).

First create a new RT email address. You can call it whatever you like, I use "noreply" in my environment. Here is an example line in /etc/aliases:

''noreply: "|/opt/rt4/bin/rt-mailgate --queue General --action correspond --url http://rt.example.com/"''

Next, modify the default (out-of-the-box) Scrip called "On Correspond Notify Requestors and Ccs").
Toggle the "Condition" to "User Defined" and copy/paste the Condition below into your Scrip.
Please be sure to modify the following line in the Condition, replacing "noreply" with the new RT email address you created:
''if ($address =~ m/noreply/) {''

# INTERRUPT NORMAL CORRESPONDENCE, DON'T SEND MAIL IF
# ANY ADDRESS ON THE EMAIL MATCHES 'NOREPLY@example.com'

# THIS EFFECTIVELY ALLOWS A NEW RT ADDRESS ("noreply") THAT
# ACTS AS CORRESPONDENCE (REQUESTOR WILL SEE IT IN THE WEB
# UI), BUT IT SUPPRESSES THE NOTIFICATION.

# THIS IS USEFUL IN SITUATIONS WHERE YOU WANT TO EMAIL A
# COMMENT INTO THE SYSTEM THAT THE REQUESTOR IS FREE TO READ,
# BUT THEY ARE NOT BOTHERED BY EMAILS.
# FOR EXAMPLE, THE ADMIN WORKING ON THE TICKET CAN NOW EMAIL A
# TRANSCRIPT OF THE PHONE CONVERSATION THEY JUST HAD WITH THE
# REQUESTOR INTO RT. THE REQUESTOR CAN READ THE COMMENT BUT IS
# NOT BOTHERED BY AN EMAIL COPY OF WHAT WAS JUST SAID ON THE PHONE.
# ADDITIONALLY, THIS IS HELPFUL WHEN END USERS DON'T CORRESPOND
# DIRECTLY WITH THE SYSTEM (e.g. ADMINS FORWARD MAIL ON THEIR
# BEHALF).

my $Ticket = $self->TicketObj;
my $Id = $self->TicketObj->id;
my $Trans = $self->TransactionObj;
my $FirstAttch = $self->TransactionObj->Attachments->First();

# BAIL OUT UNLESS THIS IS OF TYPE: Correspond
# (e.g. IF IT IS OF TYPE: Create, Comment, etc)
return 0 unless $Trans->Type eq "Correspond";

# GET THE MESSAGE ATTACHMENT:
my $msgatt = $Trans->Message->First;

# PROCEED NORMALLY (GO AHEAD AND NOTIFY REQUESTORS) UNLESS THERE IS
# A MESSAGE ATTACHMENT (AND THEREFORE IS COMING FROM EMAIL)
return 1 unless $msgatt;

# VARIABLE-IZE WHO THE EMAIL WAS SENT TO:
my $to = $FirstAttch->GetHeader('To');
my $cc = $FirstAttch->GetHeader('Cc');
my $bcc = $FirstAttch->GetHeader('Delivered-To');

# FOR FULL DEBUGGING (COURTESY BEST PRACTICAL), UNCOMMENT THESE NEXT 4 LINES:
# use Data::Dumper;
# warn "Headers are: " . $self->TransactionObj->Attachments->First->Headers;
# my $address_ref = $self->TransactionObj->Attachments->First->Addresses();
# warn "Addresses are: " . Dumper($address_ref); warn "Bcc is: " . $address_ref->{'Bcc'}[0]->as_string;

# ANOTHER CHANGE TO GET OUT, THIS TIME IF THE "To:" ADDRESS IS EMPTY:
return 1 unless ($to);

# CREATE AN ARRAY OF EMAIL *OBJECTS*
my @addr = Mail::Address->parse($to);
my @ccaddr = Mail::Address->parse($cc);
my @bccaddr = Mail::Address->parse($bcc);

$RT::Logger->debug("Scrip #5: DEBUG: To contains " . scalar(@addr) . " addresses.");
$RT::Logger->debug("Scrip #5: DEBUG: Cc contains " . scalar(@ccaddr) . " addresses.");
$RT::Logger->debug("Scrip #5: DEBUG: Bcc contains " . scalar(@bccaddr) . " addresses.");

push (@addr, @ccaddr);
push (@addr, @bccaddr);

my ($address);
foreach my $addrobj (@addr) {
$address = lc $RT::Nobody->UserObj->CanonicalizeEmailAddress($addrobj->address);
$RT::Logger->debug("Scrip #5: Ticket #$Id correspondence (Canonicalized) address = $address");
if ($address =~ m/noreply/) {
$RT::Logger->info("On Correspond Notify Requestors and Ccs for ticket #$Id -- this email was sent to the 'NoReply' address ($address) - suppressing notifications for this transaction.");
return 0;
}
}

# MAKE SURE WE HAVE AN ADDRESS TO WORK WITH:
# return 1 unless ($address);

return 1;