We found that sometimes incoming email did not actually get created as a new JIRA issue. Instead, JIRA (5.1.3) replies with an email stating that a new issue is created, but the issue id in the reply mail belongs to an existing issue.
In the latest case we saw, the issue id in the reply mail is of an issue created 30 days ago. So, effectively apart from the email, the new issue is lost from JIRA.
How does the email handler find project's latest issue id to create a new issue? What do we need to do to troubleshoot this?
Jira's standard incoming mail handlers look for an issue ID in the subject first. So if you send Jira an email with something like "About that Jira issue ABC-123", then (assuming ABC-123 is an issue) it will attach the mail as a comment.
If it cannot make that association, then it creates a new issue in the project you have configured the handler to put the issues into. The system uses the same code as a human typing a new issue in - it get's a new issue id allocated in the same way all the other "create issue" methods do.
But I thnk you mean you're just getting comments on issues.
Thanks Nic. I'm looking at mail handler creating new issue. I doubt that it gets the latest ID the same way Create issue function does.
Or if it does, then it wouldn't agree with the fact that the (supposedly 'new') issue ID (shown in the automatic reply when issue created) is in fact an ID that was used 30 days ago.
What I'm trying to understand is how could an old ID gets picked up by the mail handler. Is there any reference table that keeps the latest ID?
It gets a new number in exactly the same way create issue via the ui does.
I think the problem is before the create, it's the decision on whether to call "create" or "comment", it's never getting to "create" because it's picking up the email as a comment.
I'm not clear on exactly what you are seeing here though - could you lay out the results of some basic testing and tell us what mail handler you're using and how it's configured?
Ok. Here's the initial email sent to the mail handler. EXTELSUPPORT is the inbox that mail handler has access to.
From: Morozova, Marharyta
Sent: 30 May 2014 09:45:13 (UTC) Dublin, Edinburgh, Lisbon, London
Subject: IBR for firm ID 13461
Could you please move start/end date for the below Surveys to the future
Could you please attach the following sectors to region Global
UK Small & Mid Caps
And here's what JIRA replies:
From: Marharyta Morozova (JIRA)
Sent: Friday, May 30, 2014 3:47 PM
To: Hellen, Chris
Subject: [JIRA] (EXTEL-1059) IBR for firm ID 13461
The id EXTEL-1059 in the email was used on May 2. The latest one at the time of this email was EXTEL-1135, which was supposed to be for this issue.
As for the email, the link EXTEL-1059 actually lead to old EXTEL-1059 on JIRA. So this email from Magarita was never actually created as a new issue.
Hmm. I've got a sneakily horrid idea on what it might be doing, but before I ramble at length, I should check a bit more.
You mention EXTEL-1135, which I'm not sure about. Could you confirm that no new issue has been created at all by this email? In ANY project?
Secondly, does EXTEL-1059 have any comment added to it by this email?
Third, are you using a customised workflow for the issues in the EXTEL project? (Focus on EXTEL-1059 if you are using many workflows)
Finally, have you customised your email templates in any way?
I like horror and suspense so I will continue to indulge this:
1. Absolutely no. Searched using both reporter and parts of email subject on issue summary.
2. EXTEL-1059 has no comment / user name that resembles the email.
3. JIRA default workflow scheme.
4. I think there is because there's the company brand on the email, but I don't know to what degree.
No, this randomly occurred within EXTEL. Because it seems to be specific to this project, I'd think each project should have stored the 'latest' counting ID somewhere.
I know JIRA has one for the whole instance. We had an incident once where this number was out of sync with the actual maximum issue number, and the result was that no new issue can be created at all.
Of course there's a "latest" counter for a project, but it's nothing to do with email. Neither is the database-id counter.
If the email is going to create an issue, it uses the same process that the UI does. Or REST. Or the listeners and post-functions that create issues as part of the workflow. I'm not sure why you keep coming back to it.
Could you tell us, is it always EXTEL-1059 you get the email for?
Bump. We are encountering this issue on our JIRA instance. On-premise v 6.3.11.
Tickets created through Incoming Email reuse existing ticket numbers. Apart from the email response notifying us that a ticket was created, the issue is lost. In this case:
I have read it, and it is totally unclear. Ignoring requests for clarification is not going to get you any help. What does "reuse" mean? What *exactly* is happening here - you send Jira an email, and you get what? I can see you get a response mail, but what does "the ticket gets lost" mean? What mail handler are you using? What does the log say?
This is related to the title of the topic and the original posting, so I did not bother to duplicate existing information. When JIRA collects email through IMAP Incoming Email it tries to create an issue with an issue number that already exists. I get a workflow email which says a ticket has been created, referencing a ticket number that has existed for months prior. Ticket gets lost = No ticket is created by JIRA No error messages in the log file.
So, it's not "reusing" numbers at all. It is responding with an email referring to an old issue, and not creating a new issue (not quite the same as the original post, but close). In other words, "A Ticket mailed in last night was assigned issue number of SYS-9185." is not true, you are getting an "issue created" email that tells you that, but the issue is an old one and a new issue is not being created. However, your screenshot is accompanied by text saying that issues are being created by email - can you just confirm that those are from a time when it was working correctly? I have seen this happen before, when someone messed up permissions in the application - Jira was trying to create a temporary file to build an email from, but couldn't clear the working space, so it picked up an old file and sent that instead. The difference here is that a new issue *was* created by that process, it was just that the email was wrong. Could you check all the file ownership and permissions for the installation? Also, which handler are you using?
Hi Nic, I forgot to detail some things. My problem is exclusively with the Service Desk plugin. In this case I have no handler configured, because i think Service Desk do it automatically under the hood when we had configured the project. The subject of the e-mail does not matter in my case. Sometimes all works fine, then suddenly the error begins. For example: we have a Service Desk project with a project key named SD. Our last issue is SD-18. If i try to open a request by e-mail, JIRA returns an e-mail to me telling that the new request is SD-12. If i send another request, now it tells me that it is the request SD-13. It seems that JIRA is using a different counter for issues opened by e-mail and nothing happened (no issue is created and no comment is added). If I try to open an issue manually via JIRA everything works fine. It's very weird.
I am running across this very same issue. Was a resolution ever found? Sometimes, when my customers email to create an issue, the response they receive provides an issue key that has already been used and also the link provided points to the earlier issue, which may or may not already be closed. It seems that half the time or more, the email creates an issue correctly, but certainly we are experiencing intermittent problems, as described in the initial post/question.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot