[rt-users] mail to requestors and owners throughout ticket life
Phil Homewood
pdh at snapgear.com
Tue Jan 28 01:04:55 EST 2003
Malcolm Herbert wrote:
> OnCreate AutoreplyToRequestors with template helpdesk Autoreply
> OnCorrespond NotifyRequestorsAndCcs with template helpdesk Correspondence
> OnResolve NotifyRequestorsAndCcs with template helpdesk Resolved
> OnStatus NotifyOwner with template helpdesk StatusChange
> OnCreate NotifyAdminCcs with template helpdesk Correspondence
> OnCorrespond NotifyOwner with template helpdesk Correspondence
> OnComment NotifyOwner with template helpdesk Correspondence
>
> After this point if I reply to the AdminCc'd message with my mail
> client, or if I reply to the ticket from within the web interface or if the
> requestor replies to any of the mail they're received from the system it
> won't be delivered to me
You don't have any scrip set up to notify you OnCorrespond -- unless
you're the owner or a CC...
> (it will be added as normal to the call history
> and will appear in the web interface). Whether or not I'm the owner of
> the ticket doesn't seem to change this behaviour.
You should still get email notifications when the requestor
replies if you're the owner.
As to not being notified when /you/ reply: see
http://fsck.com/rtfm/article.html?id=5#73
> Also, mail to and from RT doesn't seem to allow threading - is there a
> way to get RT to put in an In-Reply-To: or References: header?
This is actually not quite trivial. While it's not hard to make
SendEmail.pm construct a list of references from the ticket
history, it will only get *inbound* messages. Messages sent
*from* RT don't get their Message-IDs recorded in the database.
This could be fixed. However, Message-IDs currently contain the
Ticket ID and Transaction ID; if we're going to store this as
part of the Transaction, we won't have the Transaction ID to
store -- we only get that /after/ we've made the transaction.
Attached is a patch against SendEmail.pm which makes it
add the References header. If anyone wants to tackle the
Message-ID-stored-in-database chicken-and-egg, feel free. The
Message-ID creation will need to be moved from SendEmail.pm
to Ticket.pm, around where the RT-Send-Cc headers are added.
Or maybe not -- anyone got a better idea?
--
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh at snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
-------------- next part --------------
Index: SendEmail.pm
===================================================================
RCS file: /cvs/local/rt/lib/RT/Action/SendEmail.pm,v
retrieving revision 1.3.2.2
diff -u -r1.3.2.2 SendEmail.pm
--- SendEmail.pm 28 Jan 2003 05:58:24 -0000 1.3.2.2
+++ SendEmail.pm 28 Jan 2003 05:58:27 -0000
@@ -236,6 +236,9 @@
sub SetReferences {
my $self = shift;
+ my $refs;
+
+ my $txns = $self->TicketObj->Transactions;
# TODO: this one is broken. What is this email really a reply to?
# If it's a reply to an incoming message, we'll need to use the
@@ -247,9 +250,16 @@
('In-Reply-To', "<rt-".$self->TicketObj->id().
"\@".$RT::rtname.">");
-
- # TODO We should always add References headers for all message-ids
- # of previous messages related to this ticket.
+ while (my $txn = $txns->Next) {
+ if (defined($txn->Message->First)) {
+ if (defined(my $ref = $txn->Message->First->GetHeader("Message-ID"))) {
+ $refs .= " " . $ref;
+ }
+ }
+ }
+ if (defined($refs)) {
+ $self->SetHeader('References', $refs);
+ }
}
# }}}
More information about the rt-users
mailing list