[rt-users] dealing with Cc:

[Ben Goodwin]

>
> On Mon  5.Jan'09 at 15:10:25 +0200, Razvan Cosma wrote:
> >     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20090106/f84d2fe7/attachment.htm>