-
Suggestion
-
Resolution: Unresolved
-
None
-
17
-
55
-
NOTE: This suggestion is for Jira Service Management Data Center. Using Jira Service Management Cloud? See the corresponding suggestion.
Experienced Behaviour
- Customer sends email to a Jira Service Management project that has been configured to receive email.
- Jira retrieves this message from the mailbox and processes it with errors. A ticket is not created and no notifications are sent to the customer.
Expected Behaviour
- The customer is notified that the email was received but the issue could not be created
- The Service Desk Manage, Jira Administrator, or Agent, receives some notification that an email was received but a issue could not be created or updated
Example:
Using the Welcome to Service Desk (DESK) project with default request types
- Email configured to create "Get IT Help" type issue
- This request type has two two required fields, summary and description.
- Customer sends email to service desk
- Customer includes a subject but leaves the body of the message blank
The message is processed by Jira with errors. No notification is received by the customer, agent, or administrator.
atlassian-jira.log shows:
2014-08-07 08:57:03,516 atlassian-scheduler-quartz1.clustered_Worker-2 ERROR user@domain.com Mail handler used by JIRA Service Desk. Do not modify or delete. 10,000 [internal.feature.incomingemail.IncomingEmailManager] Message body is empty where Description field is required
Example 2:
Jira Service Desk customer is marked inactive in Jira list of users
- Customer emails reply to existing ticket
The message is processed by Jira with errors. No notification is received by the customer, agent, or administrator.
atlassian-jira.log shows:
2015-01-24 02:32:16,415 atlassian-scheduler-quartz1.clustered_Worker-3 ERROR dev0123 Mail handler used by JIRA Service Desk. Do not modify or delete. 10,200 [internal.feature.emailchannel.IncomingEmailManager] You do not have permission to create comments
Workaround
Jira Service Management Data Center and Server 5.1 includes a new email channels audit log. You can now easily check if the connection with your email channels is active and make sure all incoming emails are being processed correctly. The audit log consist of two different tabs:
- A processing log that shows every message received from the connected email account. It allows you to search and filter to find specific emails.
- A connectivity log. Jira Service Management attempts to connect to and pull new messages from your email channel every 60 seconds. The connectivity log shows the history of the results of each attempt.
See here for further information.
While this doesn't directly resolve this suggestion, it does provide more information for admins to monitor the status of email channels and incoming emails.
- is duplicated by
-
JSDSERVER-3841 Request (created via email) do not bounce for people not on the customer list
-
- Gathering Impact
-
-
- Gathering Interest
- relates to
-
- Closed
-
- Gathering Interest
-
- Gathering Interest
-
- Gathering Interest
-
- Gathering Interest
-
- Gathering Interest
-
- Reviewing
- links to
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-818] JSM should send reply or notification when mail handler cannot create or update issue
Hi scharnowski it is possible to export the original email from the database. Refer to the following article for details:
If you require help please submit a new support request so that our team may assist.
Cheers!
Tim | Atlassian
We are facing the same problem and i had to find a workaround for this problem. It's not the best one but maybe it could help someone else as well. You need to have access to the database to use this one. All of the processed emails (this includes those that didnt create an issue as well) get an entry into a service desk database table (AO_2C4E5C_MAILITEMAUDIT). So we wrote a script that selects all entries with the RESULT_STATUS = "FAILED" and if we could find a new one since the last time this script ran, we send an email to our service agents. However this entry only contains the sender address not the content of the email. Our service desk agents are able to look into the Jira service desk email address (be careful with this permission), to check if its necessary to do anything or not.
We have this script running hourly and it helped us out greatly. One could check the log inside of the Jira GUI by himself, but this is even more tedious than our solution we assume. Hope this helps someone, while Atlassian seems to do nothing about it (for 4 years now).
When a different e-mail address e-mails to the configured address, it's written in the log that the specific user does have permissions to create an issue, however the customer is not notified it has no access to the service desk.
As well you as a support or JIRA admin will not see that something goes wrong.
Another way of having this resolved would be to implement a forward address. Like any other JIRA mail handler expect than JIRA Service Desk to forward mails that can not be processed.
Another example;
Set the option that only customers in this project are allowed to raise requests. When a different e-mail address e-mails to the configured address, it's written in the log that the specific user does have permissions to create an issue, however the customer is not notified it has no access to the service desk.
An e-mail should be send back to the customer, allowing him to request access to the specific service and an admin / project admin should be notified somewhere about this dropped e-mail.
I would like to see an administrative option that, when set, will cause JIRA to create (or update) an issue for every email received.
In my case, we're connected to Active Directory for user authentication and JIRA will refuse to process an email received from a user who's marked "inactive" (disabled in AD). Unacceptable!
I agree. It's insane that JIRA could not process an email and not alert anyone about it. Makes me look like I'm giving my clients terrible service when something gets lost. Can you implement this already?
+1