Avoiding Duplicate Issues

[Phillip Yero]

My question is not necessarily how to resolve a specific problem, just looking for advice on how to deal with some confusion.

We have multiple developers who address help tickets. Sometimes, two similar help tickets come in from the same customer - but from different users - about the same issue. When two different developers each pick up one of the tickets, two similar issues get created in JIRA that actually address the same original problem. Not only does this waste the time it takes to create the duplicate issue, but many times the developers will each be working on their tickets at the same time.

Is there anyone who has advice on how to deal with this?

[codelab expert · Accepted solution]

Have a look at this plugin: Suggestimate

[Phillip Yero]

This looks perfect. Thanks!

[BenP]

i have suggestimate, but am looking for a way to cover ALL input streams that lead to issue creation, e.g. issue creation based on incoming email, ; issue creation via JIRA capture, ServiceDesk, etc..

It'd be helpful to be able to get the same similar issues list via REST or JQL, so i can generate the same 'similar issues' report and use that in an an automated return email to the email sender

[James Strangeway]

Would it be possible to limit who can enter issues into JIRA? By that I mean instead of triage on your end, have the customer funnel it through one person on their end. This way the person entering the issues would know if it was a duplicate or not.

[Phillip Yero]

I wish that were possible! No, the customers are too disparate for that to be workable.

[C_ Faysal]

I've seen a groovy script that can be called by script runner plugin. I think it was called "autodupes" or something like that. Give it a shoot

[kiranmai genkolla]

hi @C_ Faysal ,

Can you please guide us using the script runner on how to restrict the duplicate tickets created via email.

[PhilB]

My first thought is that it depends on how quickly tickets are coming in and how quickly they tend to get resolved.

Nearly any solution to this problem will involve soem sort of pattern matching either by software or a human.

The easiest thing to do would be to setup a triage process so incoming issues go through one person who is responsible for reviewing and assigning issues to a queue for your developers to work on. This only works if the volume of tickets is managable and the response time is measured in hours vs minutes. You could also subdivide the triage work by assigning things to triage queues (people) based on component lead.

Humans are naturally good at pattern matching but if you can't use them then you'll have to find some sort of soiftware based solution that looks at issues tryign to find potential conflicts/overlaps.