-
Bug
-
Resolution: Fixed
-
High
-
2.0.2, 2.0.3
NOTE: This bug report is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding bug report.
Steps to reproduce
- Install Service Desk (v 2.0.2)
- Create a Service Desk
- Enter that Service Desk and click Settings > Email settings
- Turn on email requests and enter valid credentials for an email account (servicedesk@example.com)
- Send email to another party and CC this email to servicedesk@example.com
Expected Results
- Email will be processed by the Service Desk mail handler
- Issue will be created in Service Desk
Actual Results
- Issue is processed but not created in Service Desk
- The following will appear in the atlassian-jira-incoming-mail.log (debug mode enabled)
The message has been rejected (This email address is not used by this service desk any more.)
If To field is left empty, mail handler throws a nullpointer exception and stops handling any messages after that
2014-09-30 10:31:48,447 atlassian-scheduler-quartz1.clustered_Worker-4 ERROR anonymous Mail handler used by JIRA Service Desk. Do not modify or delete. 10,000 [atlassian.jira.service.ServiceRunner] An error occurred while trying to run service 'Mail handler used by JIRA Service Desk. Do not modify or delete. 10,000'. null java.lang.NullPointerException at scala.collection.mutable.ArrayOps$ofRef$.length$extension(ArrayOps.scala:114) at scala.collection.mutable.ArrayOps$ofRef.length(ArrayOps.scala:114) at scala.collection.SeqLike$class.size(SeqLike.scala:106) at scala.collection.mutable.ArrayOps$ofRef.size(ArrayOps.scala:108) at scala.collection.mutable.Builder$class.sizeHint(Builder.scala:69) at scala.collection.mutable.ListBuffer.sizeHint(ListBuffer.scala:45) at scala.collection.TraversableLike$class.to(TraversableLike.scala:628) at scala.collection.mutable.ArrayOps$ofRef.to(ArrayOps.scala:108) at scala.collection.TraversableOnce$class.toList(TraversableOnce.scala:257) at scala.collection.mutable.ArrayOps$ofRef.toList(ArrayOps.scala:108) at com.atlassian.servicedesk.internal.feature.incomingemail.IncomingEmailService.com$atlassian$servicedesk$internal$feature$incomingemail$IncomingEmailService$$getEmailSettingFromMessage(IncomingEmailService.scala:101) at com.atlassian.servicedesk.internal.feature.incomingemail.IncomingEmailService$$anonfun$createIssueFromEmail$1.apply(IncomingEmailService.scala:61) at com.atlassian.servicedesk.internal.feature.incomingemail.IncomingEmailService$$anonfun$createIssueFromEmail$1.apply(IncomingEmailService.scala:60) at scala.util.Either$RightProjection.flatMap(Either.scala:523) at com.atlassian.servicedesk.internal.feature.incomingemail.IncomingEmailService.createIssueFromEmail(IncomingEmailService.scala:60) at com.atlassian.servicedesk.internal.feature.incomingemail.IncomingEmailService.processEmail(IncomingEmailService.scala:48) at com.atlassian.servicedesk.internal.email.SDMailHandler.processMessage(SDMailHandler.java:36) at com.atlassian.servicedesk.squalor.email.AbstractMailHandler.handleMessage(AbstractMailHandler.java:100) at com.atlassian.servicedesk.squalor.email.SDMessageProcessor.execute(SDMessageProcessor.java:77) at com.atlassian.servicedesk.squalor.email.ServiceDeskMailFetcherService.runImpl(ServiceDeskMailFetcherService.java:71) at com.atlassian.jira.service.services.file.AbstractMessageHandlingService.run(AbstractMessageHandlingService.java:261) at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:66) at com.atlassian.jira.service.ServiceRunner.runService(ServiceRunner.java:75) at com.atlassian.jira.service.ServiceRunner.runServiceId(ServiceRunner.java:53) at com.atlassian.jira.service.ServiceRunner.runJob(ServiceRunner.java:36) at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:135) at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:101) at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:80) at com.atlassian.scheduler.quartz1.Quartz1Job.execute(Quartz1Job.java:32) at org.quartz.core.JobRunShell.run(JobRunShell.java:223) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
Environment
- I tested this with the following
- JIRA 6.3.5a
- Service Desk 2.0.2
- Mail Server = gmail
Notes
- User is already customer. When sending directly to the email, issue will be created. When CC the email, issue not created
- I've tested with regular mail handler (Create a new issue or add a comment in an existing issue). Issue will be created even when email is CC'd
- I'm not sure if this is expected behaviour or not, but because CC'ing the email will create the issue in a regular mail handler, I am creating this as a bug
- is duplicated by
-
-
- Closed
-
- is related to
-
JSDSERVER-1040 Cannot handle 'bulk' or email not specifically sent to service desk support email
- Closed
- relates to
-
-
- Closed
-
-
SHER-33 Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-827] Email CC'd to Service Desk email or a group doesn't get created as issue
Martyn Simpson
added a comment - I noticed that it all relates to what it is in the TO field of the header.
With Google when you send to a group it arrives in the Inbox of the user with the TO field of the group address NOT of the person's email address. This means that JIRA ignores it. Other software I have used simply looks in the Inbox (or other folder) and picks up everything within it. This mean that you could have one Person in Google with multiple aliases and or group memberships, set up rules to send the email to a group within Google (skipping the inbox) then point the mail collectors for project A to collect from ProjA IMAP folder, Project B to ProjB IMAP folder etc. For people using Google or Hosted exchange, where every Person costs money, running a JIRA system with 10 Projects with 10 email collectors would require 10 individual email accounts.
Hope this helps.
Martyn Simpson
added a comment - I noticed that it all relates to what it is in the TO field of the header.
With Google when you send to a group it arrives in the Inbox of the user with the TO field of the group address NOT of the person's email address. This means that JIRA ignores it. Other software I have used simply looks in the Inbox (or other folder) and picks up everything within it. This mean that you could have one Person in Google with multiple aliases and or group memberships, set up rules to send the email to a group within Google (skipping the inbox) then point the mail collectors for project A to collect from ProjA IMAP folder, Project B to ProjB IMAP folder etc. For people using Google or Hosted exchange, where every Person costs money, running a JIRA system with 10 Projects with 10 email collectors would require 10 individual email accounts.
Hope this helps. 
Helalur Khan
added a comment - We have also realised that there is another issue, the email address <domain>.net has an alias <domain>.com and it does not create tickets when something is sent to the .com address
Helalur Khan
added a comment - We have also realised that there is another issue, the email address <domain>.net has an alias <domain>.com and it does not create tickets when something is sent to the .com address 
Matt Tittler
added a comment - I ran some more testing on this issue can can confirm that the behavior is as described. Additionally, whatever happens with the CC field also happens with the BCC field (issues are skipped/the service crashes entirely). Also interesting to note, if the address is in the To field and also the CC field, a ticket is generated as is expected.
Matt Tittler
added a comment - I ran some more testing on this issue can can confirm that the behavior is as described. Additionally, whatever happens with the CC field also happens with the BCC field (issues are skipped/the service crashes entirely). Also interesting to note, if the address is in the To field and also the CC field, a ticket is generated as is expected.
This also affects 2.0.4