Searching ticket subjects

Hello,

I have installed RT and to quite an extent been able to understand and tune
it to my needs. But I have a problem: many times multiple people are
involved in a ticket and they come as CC in the mail.

I have installed one extension which extracts CC/AdminCC from the mail and
adds them to the ticket, but that doesn’t yet solve my problem which is:

New ticket gets created if it is not a reply to the automatic reply that is

What I’m thinking of doing is, doing a fuzzy search based on the requestors
/ cc when a new mail arrives and put the message as a correspondence in the
existing ticket if subject does not contain the subject tag. I think this
will be very inefficient but at least it will solve the problem of
duplicate tickets that I’m facing a lot right now.

How should I go about doing this? I couldn’t find the API for REST
mailgateway which I I see is getting called from the rt-mailgate script.

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends autoreply to
all of them. Then B thinks there should be something added so he replies to
A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and B.On Tue, Jul 12, 2016 at 6:47 PM, Kenneth Marshall ktm@rice.edu wrote:

On Tue, Jul 12, 2016 at 08:58:07AM +0530, Nilesh wrote:

Hello,

I have installed RT and to quite an extent been able to understand and
tune
it to my needs. But I have a problem: many times multiple people are
involved in a ticket and they come as CC in the mail.

I have installed one extension which extracts CC/AdminCC from the mail
and
adds them to the ticket, but that doesn’t yet solve my problem which is:

New ticket gets created if it is not a reply to the automatic reply that
is
sent by RT because their replies does not contain the queue subject tag.

What I’m thinking of doing is, doing a fuzzy search based on the
requestors
/ cc when a new mail arrives and put the message as a correspondence in
the
existing ticket if subject does not contain the subject tag. I think this
will be very inefficient but at least it will solve the problem of
duplicate tickets that I’m facing a lot right now.

How should I go about doing this? I couldn’t find the API for REST
mailgateway which I I see is getting called from the rt-mailgate script.

Hi Nilesh,

We added processing to look for a ‘In-Reply-To:’ header to help link the
Email to existing requests. It does help keep duplicate tickets from being
created. I think there are some recipes in the mailing list archives and
on the wiki.

Regards,
Ken

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends autoreply
to
all of them. Then B thinks there should be something added so he replies
to
A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and B.

Hi Nilesh,

The 2nd Email should include an In-Reply-To: header that can be used
to link it to the 1st Email’s ticket.

Regards,
Ken

Does the default RT strip that off? Because I’m not seeing in one recent
duplicate created in the manner I described.

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends autoreply to
all of them. Then B thinks there should be something added so he replies to
A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and B.

Hi Nilesh,

The 2nd Email should include an In-Reply-To: header that can be used
to link it to the 1st Email’s ticket.

Regards,
Ken

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends autoreply
to
all of them. Then B thinks there should be something added so he replies
to
A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and B.

Hi Nilesh,

The 2nd Email should include an In-Reply-To: header that can be used
to link it to the 1st Email’s ticket.

Regards,
Ken

Does the default RT strip that off? Because I’m not seeing in one recent
duplicate created in the manner I described.

Hi,

You will need to look at Email.pm to see what it does. At least that is the
name of the file in RT 3.8.13+. We are working on an upgrade to 4.4.x.

Regards,
Ken

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends
autoreply to
all of them. Then B thinks there should be something added so he
replies to
A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and B.

Hi Nilesh,

The 2nd Email should include an In-Reply-To: header that can be used
to link it to the 1st Email’s ticket.

Regards,
Ken

Does the default RT strip that off? Because I’m not seeing in one recent
duplicate created in the manner I described.

Ah it’s hidden inside ‘show full headers’. This is interesting. Is there
some documentation about this header?

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends
autoreply to
all of them. Then B thinks there should be something added so he
replies to
A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and B.

Hi Nilesh,

The 2nd Email should include an In-Reply-To: header that can be used
to link it to the 1st Email’s ticket.

Regards,
Ken

Does the default RT strip that off? Because I’m not seeing in one recent
duplicate created in the manner I described.

Ah it’s hidden inside ‘show full headers’. This is interesting. Is there
some documentation about this header?

Hi,

You can look at the RFC’s, but that was the header that provided the most
value in reducing duplicate tickets.

Regards,
Ken

I don’t think that’s going to help me.
Let me give you a scenario:

Person A sends a mail to my queue with B and C in CC. RT sends
autoreply to

all of them. Then B thinks there should be something added so he
replies to

A’s mail instead of autoreply mail.
Now I have 2 different tickets created for the same subject by A and
B.

Hi Nilesh,

The 2nd Email should include an In-Reply-To: header that can be used
to link it to the 1st Email’s ticket.

Regards,
Ken

Does the default RT strip that off? Because I’m not seeing in one recent
duplicate created in the manner I described.

Ah it’s hidden inside ‘show full headers’. This is interesting. Is there
some documentation about this header?
Hi,

You can look at the RFC’s, but that was the header that provided the most
value in reducing duplicate tickets.

Regards,
Ken

As this discussion is going on a few duplicate tickets were created in the
system and this definitely looks like a good way to solve it. Did you use
ExtractCustomFields module to get this done?

I’m thinking of doing it like this:
Run ExtractCustomFields on every correspond to get the Message ID out of the
headers. Then I can search through this field probably using a customized rt-
mailgate. Does that sound good? I don’t think there’s a way using scrips because
by the time scrip executes ticket is already created (unless something is
possible in the “On transaction” condition).

Does the default RT strip that off? Because I’m not seeing in one recent
duplicate created in the manner I described.

Ah it’s hidden inside ‘show full headers’. This is interesting. Is there
some documentation about this header?
Hi,

You can look at the RFC’s, but that was the header that provided the most
value in reducing duplicate tickets.

Regards,
Ken

As this discussion is going on a few duplicate tickets were created in the
system and this definitely looks like a good way to solve it. Did you use
ExtractCustomFields module to get this done?�

I’m thinking of doing it like this:
Run ExtractCustomFields on every correspond to get the Message ID out of the
headers. Then I can search through this field probably using a customized rt-
mailgate. Does that sound good? I don’t think there’s a way using scrips because
by the time scrip executes ticket is already created (unless something is
possible in the “On transaction” condition).

Hi Nilesh,

I have attached my current version of ./local/lib/RT/Interface/Email_Local.pm.
It includes our modifications gathered from the list recommendations in the function

ParseInReplyTo()

This patch is against RT 3.8.13+ and has not been updated to RT 4+ but is should
be a straight-forward update. To make your own version of Email_Local.pm, start
with just the function ParseInReplyTo() and the calling function and add functions
from ./lib/RT/Interface/Email.pm until you have a working file. That will be the
minimum that you will need. Take a look at http://requesttracker.wikia.com/wiki/Customizing
for more details. Let me know if you have any questions.

Regards,
Ken

Email_Local.pm (11.6 KB)

Does the default RT strip that off? Because I’m not seeing in one
recent

duplicate created in the manner I described.

Ah it’s hidden inside ‘show full headers’. This is interesting. Is
there

some documentation about this header?
Hi,

You can look at the RFC’s, but that was the header that provided the
most

value in reducing duplicate tickets.

Regards,
Ken

As this discussion is going on a few duplicate tickets were created in
the
system and this definitely looks like a good way to solve it. Did you use
ExtractCustomFields module to get this done?

I’m thinking of doing it like this:
Run ExtractCustomFields on every correspond to get the Message ID out of
the
headers. Then I can search through this field probably using a
customized rt-
mailgate. Does that sound good? I don’t think there’s a way using scrips
because
by the time scrip executes ticket is already created (unless something is
possible in the “On transaction” condition).

Hi Nilesh,

I have attached my current version of
./local/lib/RT/Interface/Email_Local.pm.
It includes our modifications gathered from the list recommendations in
the function

ParseInReplyTo()

This patch is against RT 3.8.13+ and has not been updated to RT 4+ but is
should
be a straight-forward update. To make your own version of Email_Local.pm,
start
with just the function ParseInReplyTo() and the calling function and add
functions
from ./lib/RT/Interface/Email.pm until you have a working file. That will
be the
minimum that you will need. Take a look at
http://requesttracker.wikia.com/wiki/Customizing
for more details. Let me know if you have any questions.

Regards,
Ken

This works perfectly, thanks a lot. I wonder why this hasn’t been
integrated as a core feature.