First time poster here. Frequently we have users CC our help desk email address (so the support team stays in the loop) when emailing others. As a result, through the process of emailing and ‘reply all’, our RT system generates many duplicate tickets.
It was suggested to try a MapToExistingTicket plugin extension as it would handle duplicate tickets with the same subject and also Re: (Re: Re: Re:) etc.
I’ve installed the plugin following README instructions, added the local_attachments1 index to the attachments table, updated RT_SiteConfig.pm with the extension, sudo rm -rf /opt/rt4/var/mason_data/obj, and restarted httpd.
However, when I test the extension by generating an email (using the mail -s command) and subsequent emails using the same subject or re: , I am still getting just as many duplicate emails.
I’m hoping someone might have a suggestion to either troubleshoot the plugin or offer up alternative solutions? Ultimately I think it could be fixed at the source with better user training but we have many users that may or may not follow the help desk team’s advice.
I don’t believe that extension is on metacpan, but I believe the code you are referencing uses email headers to find existing tickets. Meaning having the same subject won’t work.
If you Cc another email address in your first email into RT then when the other address replies to all the headers from the original email will be present allowing RT to try and find the existing ticket.
it seems to be an all time topic how to avoid those duplicate tickets which occur if one replies to a Cc thread out of the original RT scope. We are facing this scenario several times a day. This this should affect many users imho.
It’s working fine in general (no more duplicates) - there’s just one caveat I could not solve until now: We are using different Queues and Subject Tags, and the mentioned extension seems somehow only to refer to the configured value of $rtname, such it happens sometimes, that a second Subject Tag gets added to a reply. This concerns Queues where another Subject Tag is configured individually.
It does not break the overall function, but it does not look nice.
I would like to see such an Extension as part of the RT upstream. Really wondering why this did not happen until now.
@JeramyMT Which Extension are you using? Can I find it somewhere? @D3_cwhite Maybe you like to ask your colleague to also fix the above mentioned wrong subject tag insertion?
:Filter::CheckMessageId
