[rt-users] 3rd party reply on a ticket creates a new ticket

[Ian Marlier]

On 8/2/07 6:39 PM, "Kris Boutilier" <Kris.Boutilier at scrd.bc.ca> wrote:

>> -----Original Message-----
>> From: rt-users-bounces at lists.bestpractical.com
>> [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf
>> Of Joe Casadonte
>> Sent: Thursday, August 02, 2007 12:22 PM
>> To: rt-users
>> Subject: [rt-users] 3rd party reply on a ticket creates a new ticket
>> 
>> Using RT 3.6.3....
>> 
>> I have the following situation:
>> 
>> * user A creates a ticket copying list B
>> * user C (a member of B) replies to the ticket with more information
>> * a second ticket is created, even though user C's email was tagged
>>    correctly in the subject line
>> 
>> If user C is directly CC'd (instead of through an email list,
>> which RT obviously has no way of knowing about), then the
>> reply goes into the original ticket as desired.  Is there a
>> way to prevent RT from creating a new ticket when anyone
>> replies to a ticket?
>> 
> {clip}
> 
> Are you certain that User C is replying to the email generated by RT and
> not to the message that User A cc:ed to the list? We have experienced
> the same behavior where User A sends a new request directly to RT and
> CC's many additional users. One or more of those users enter into a
> debate using 'Reply All' and each and every reply to that exchange of
> emails lacks the RT subject line prefix and so spawns a raft of new
> tickets. As a I understand it it's only the lack of a valid subject line
> prefix that will cause RT to spawn a new ticket.
> 
> We're looking for a way to have RT just reject messages that it's cc:ed
> into, period, to avoid this situation. I suspect that would have to
> occur at the MTA level but I'm not certain how we'd do that as we're
> using the Sendmail aliases table.

Just as an aside on this thread, possibly most of interest to Best
Practical: I'm using effectively the same setup that Kris describes above.
Almost all of my users describe themselves as very satisfied with the RT
system, but that this particular situation (multiple tickets opening due to
CC's, etc) is their one significant complaint.  The signal-to-noise ratio
becomes significantly smaller, depending on the config of specific queues.

(Yes, I have some picky users)

I've often wondered whether it would be possible to do some kind of an
(optional) caching mechanism for message bodies; if greater than, say, 90%
of the text of a cached message body is contained in a new request, then
assume that the two are related (or just create a single-click link to merge
the two, or something).

In my experience, a body-text-cache that held that text for 60 minutes would
be sufficient to eliminate all but a few stragglers of this particular type
of annoyance.

Perhaps not feasible...but if it was, it would be neato :-)

- Ian