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.
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.
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.
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.
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.
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.
Ken, I have this problem as well (replying to a message that was CCed to RT creates a new ticket rather than adding to the existing ticket). However, I get a 404 when trying to download your attached Email_Local.pm. Do you happen to still have a copy you could re-upload? Thanks!
This extension looks like it will do what I need, but I can’t get it to install and there is basically not much debugging info to help me work out what’s wrong. I’ve got the file from the repository above @D3_cwhite but when I try to install:
support.dev:/srv/download/RT-Interface-Email-Filter-CheckMessageId-master# perl ./Makefile.PL
include /srv/download/RT-Interface-Email-Filter-CheckMessageId-master/inc/Module/Install.pm
Unknown function is found at ./Makefile.PL line 4.
Execution of ./Makefile.PL aborted due to runtime errors.
If you're a contributor to a project, you may need to install
some Module::Install extensions from CPAN (or other repository).
If you're a user of a module, please contact the author.
I’m guessing it’s missing some perl module or something. Other extensions install okay though.
Hmm Thanks. The Makefile.PL is as downloaded. It fails from the original cpan install as well.
Hadn’t thought that is might be a function.
The error just suggests “you may need to install some Module::Install extensions from CPAN” but no idea how to work out what it may need. So possibly it needs some Module::Install thingy which I haven’t got, but it’s not going to help me out and tell me which one I might need!
Perhaps all it does in the end is copy the file into the correct location anyway.
.