Dealing with Cc:

Hello,
I’m trying to figure out the best way to deal with a common issue we have
when multiple recipients are specified for a message. If a customer sends a
message to our ticket system with a dozen other persons in to: and/or cc:,
it will be stored correctly, but

  1. If any of the other recipients replies to the initial message, keeping RT
    in Cc: a new ticket will be created, with him/her as requestor. Is it
    possible for RT to detect such replies and store them as part of the same
    issue?
  2. When sending messages from RT to a list of Cc: each recipient will only
    see the RT alias as originator, so replies will not be seen by the others.
    Is this a configurable option?
Hello,

I’m trying to figure out the best way to deal with a common issue we have
when multiple recipients are specified for a message. If a customer sends
a message to our ticket system with a dozen other persons in to: and/or
cc:, it will be stored correctly, but

  1. If any of the other recipients replies to the initial message, keeping
    RT in Cc: a new ticket will be created, with him/her as requestor. Is it
    possible for RT to detect such replies and store them as part of the same
    issue?

The problem is that it’s relatively hard to do this right. Most of the
ways one could do this would result in RT accidentally aggregating all
sorts of unrelated messages. In particular, there’s a user behaviour
that makes this work really poorly:

Users frequently craft new messages by clicking “reply” or “reply all”
and blanking out the subject and body. In at least one of the most
common mail clients (outlook), this means you end up with a message that
has the In-Reply-To: header but isn’t actually a reply.

Coping with both sides of this would require some engineering work,
though I do have a design for a system that would make you happy. It’s a
fair bit of work, though.

  1. When sending messages from RT to a list of Cc: each recipient will only
    see the RT alias as originator, so replies will not be seen by the others.
    Is this a configurable option?

The configuration option is in RT_Config.pm - RT can automatically add
all of a ticket-creating-message’s recipients as ccs on the ticket, so
RT automatically routes all replies to all those folks.

Jesse

Would a check like “if Subject: line is the same as an existing ticket and
the requestor of that is in To: or Cc: then ignore in-reply-to and consider
the message as a comment on” work?On Mon, Jan 5, 2009 at 4:06 PM, Jesse Vincent jesse@bestpractical.comwrote:

On Mon 5.Jan’09 at 15:10:25 +0200, Razvan Cosma wrote:

  1. If any of the other recipients replies to the initial message,
    keeping
    RT in Cc: a new ticket will be created, with him/her as requestor. Is
    it
    possible for RT to detect such replies and store them as part of the
    same
    issue?

Users frequently craft new messages by clicking “reply” or “reply all”
and blanking out the subject and body. In at least one of the most
common mail clients (outlook), this means you end up with a message that
has the In-Reply-To: header but isn’t actually a reply.

Coping with both sides of this would require some engineering work,
though I do have a design for a system that would make you happy. It’s a
fair bit of work, though.

Hello,

I’m trying to figure out the best way to deal with a common issue we
have
when multiple recipients are specified for a message. If a customer
sends
a message to our ticket system with a dozen other persons in to:
and/or
cc:, it will be stored correctly, but

  1. If any of the other recipients replies to the initial message,
    keeping
    RT in Cc: a new ticket will be created, with him/her as requestor. Is
    it
    possible for RT to detect such replies and store them as part of the
    same
    issue?

The problem is that it’s relatively hard to do this right. Most of the
ways one could do this would result in RT accidentally aggregating all
sorts of unrelated messages. In particular, there’s a user behaviour
that makes this work really poorly:

Users frequently craft new messages by clicking “reply” or “reply all”
and blanking out the subject and body. In at least one of the most
common mail clients (outlook), this means you end up with a message that
has the In-Reply-To: header but isn’t actually a reply.

Coping with both sides of this would require some engineering work,
though I do have a design for a system that would make you happy. It’s a
fair bit of work, though.

How about if this other header (such as In-Reply-To:) matches AND the
subject (minus prefixes) match, then route the reply into an existing
ticket? So:

If subject contains proper tags
route it according to the tags
else if In-Reply-To: matches an existing ticket AND the subjects match
(minus prefixes like RE: or FWD:)
route it according to what’s found
else
create new ticket

I’m guessing that metadata (in-reply-to) is not in its own field and indexed
– which is probably necessary. Then the matching logic above needs to be
written. I also don’t know what the best choice would be for header-based
matching (is In-Reply-To: the best choice?) – that might need some
research, too.

-=| Ben