-
Bug
-
Resolution: Fixed
-
Medium
-
2.0.2
Steps to reproduce
- Install Service Desk 2 (my version is 2.0.2)
- Configure mail handler through
Service Desk > Settigns > Email settings > Turn it on - Once successfully created, send multiple emails one after another immediately
- In my testing, I sent 4-6 emails immediately after each other
Expected Results
- All emails created as request in Service Desk
Actual Results
- Some emails will be left un-read in the mailbox
- Not created as request
Notes
- Not able to consistently reproduce
- Seems to be easier to reproduce when the inbox have more mails
- Tested with Gmail
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page"){kind=icon}
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-904] Not all emails processed by mail handler
grunta - we do need more information before conclude the reason of this
- Do you have an Public Sign-up Service Desk? If you don't have, then only users appear in People tab/Customer will be be able to create issues via email. With public sign-up on, Service Desk will create new account to people if they don't have account yet.
- Do you use exactly same email address that you use for Service Desk? If no, then that's the reason why email didn't create an issue for you.
- Would you mind providing any logs
Raffi Enficiaud
added a comment - @Grant Mantle: by new you mean 2.0.4? Just upgraded to the new Service Desk - emails are still appearing as unread in IMAP queue, then after a minute or so (when the Service Desk retriever goes out) it changes to 'Read'... but doesn't hit the job queue within Jira Service Desk...
Thanks
Hello,
Can you please advise on an estimated time for update release date for this email issue...
It really is causing issues / delays and relationship to our clients we support.
Can we be of any assistance to troubleshoot the issue?
Many thanks
Hi all,
We just upgraded to SD 2.0.3 and changed the previous email handler bundled with Jira to the one bundled with Service Desk. We are however encountering several issues with this new email handler that makes things more complicated than when using the default email handler. Mainly, when an email is rejected by SD, there is no proper way to check it.
- If an email address cannot be matched with the user database, the email is ignored altogether. Instead, it should be configurable to accept it using a default reporter as fallback (like it’s possible with the stock mail handler), that a developer can then change to the appropriate user.
- One the other hand, if there is more than one match to a user (let's say I have an local Jira admin and Crowd user account, both of them using the same email address), the email is also ignored.
- If the above happens (email ignored), there is nothing written to the log file, so it’s hard to debug and this is a strong blocking point in using the email handler. We have a setup that can parse the log file and report errors. We would like to be able to configure it properly and to see if an email has been rejected.
- At least with IMAP, the service desk mail handler does not remove messages from the configured inbox, like it does with the stock handler. Instead, it ignores existing messages. This is at least unexpected, if not undesired. If the email is left unread for instance, it could allow us to check what was ignored.
The rationale behind that is the following:
The reporter field depends on the configuration of the email client of the user (even if we redirect the emails to the service desk). Often the email address appearing in the client settings is not the same as the one used by Jira:
- the users use some other account, like a personal one
- there is an alias from one domain to another allowing to have eg. shorter email addresses. We have such a setup, but at the end the one that is known by Jira is the one given by Crowd, which is the one read from the LDAP (the long one).
A nice feature would be to have a user mapping, as we can do in Bamboo and Crucible.
But ignoring the emails without any kind of notification, or not having a fallback user prevents us from deploying Service Desk in our Institute.
PS.: the default email handler does not update the Service Desk fields properly so the user cannot see the emailed requests in the customer portal. So the default email handler is also not a proper solution for us.
Raffi Enficiaud
added a comment - - edited Hi all,
We just upgraded to SD 2.0.3 and changed the previous email handler bundled with Jira to the one bundled with Service Desk. We are however encountering several issues with this new email handler that makes things more complicated than when using the default email handler. Mainly, when an email is rejected by SD, there is no proper way to check it.
If an email address cannot be matched with the user database, the email is ignored altogether. Instead, it should be configurable to accept it using a default reporter as fallback (like it’s possible with the stock mail handler), that a developer can then change to the appropriate user.
One the other hand, if there is more than one match to a user (let's say I have an local Jira admin and Crowd user account, both of them using the same email address), the email is also ignored.
If the above happens (email ignored), there is nothing written to the log file, so it’s hard to debug and this is a strong blocking point in using the email handler. We have a setup that can parse the log file and report errors. We would like to be able to configure it properly and to see if an email has been rejected.
At least with IMAP, the service desk mail handler does not remove messages from the configured inbox, like it does with the stock handler. Instead, it ignores existing messages. This is at least unexpected, if not undesired. If the email is left unread for instance, it could allow us to check what was ignored.
The rationale behind that is the following:
The reporter field depends on the configuration of the email client of the user (even if we redirect the emails to the service desk). Often the email address appearing in the client settings is not the same as the one used by Jira:
the users use some other account, like a personal one
there is an alias from one domain to another allowing to have eg. shorter email addresses. We have such a setup, but at the end the one that is known by Jira is the one given by Crowd, which is the one read from the LDAP (the long one).
A nice feature would be to have a user mapping, as we can do in Bamboo and Crucible.
But ignoring the emails without any kind of notification, or not having a fallback user prevents us from deploying Service Desk in our Institute.
PS.: the default email handler does not update the Service Desk fields properly so the user cannot see the emailed requests in the customer portal. So the default email handler is also not a proper solution for us. I'm after a possible estimated fix time for this problem? - this has quite a bit of a strangle-hold on our organisation at the moment, just wanting a rough timeframe if possible....
Kindest regards - Grant
We are having the exact same issue as Grant. Could it be that the from address is not the same address on the mail handler?
I could perhaps send you my jira mail in / out logs if you would like to see what we are experiencing? - just tell me and I would be happy to assist.
Thanks
Here is a good example for you:
Processing Log states:
02/Jun/15 12:19 PM FAILURE Unable to get user. tracy.knipe@lhh.co.za [JIRA] [Liberty Health Service Desk] WEBRT SIZE LIMIT [LHSD-3883] Service Desk Mail Handler
User Tracy Knipe is an active Customer and has submitted many issues in the past - why then the error?
Thanks
Lucille