-
Suggestion
-
Resolution: Low Engagement
-
None
-
None
-
0
-
3
-
Issue Summary
If a user deletes an email channel in JIRA and creates a new one, JIRA should delete all references to this email channel in the database. Especially in the MailConnection table and the MailItem table as if there are emails that failed originally, when you remove the email channel, JIRA Service Desk should not persist these emails in the database.
Expected Behavior
Have JIRA Service Desk remove all mails related to this mailchannel with the old id once the channel is removed or set a new Status other than the ones used by by working mail channels.
Existing Behavior
JIRA would leave all data related to the mail channel that were in the process of being processed the way they were making it difficult to identify without knowing the purged ID and also, it would never process the emails anymore hence there is no reason to actually persist the data from these mail servers.
- is related to
-
JSDSERVER-5096 Invalid characters encountered in base64 data
-
- Closed
-
- mentioned in
-
Page Failed to load
[JSDSERVER-5094] Deleting An Email Channel Should Remove All Orphaned Emails
As long as the existing emails in the source system (eg: exchange server) are left alone. Then we could just mark them us unread and they should be picked up again when the email system resumes pulling them.
@Ismael, could you create a bug for the situation I described in my previous comment? When I try to create a bug in JIRA Service Desk Server project I receive "doesn't have the 'Assign Issues' permission" error
Thanks Ismael for registering this Suggestion 
To give a bit more context about the origin of this Suggestion:
The issue
One day, I noticed that my Service Desk email channel stopped processing new emails. Although emails were pulled and cleaned from the Exchange Mail Server mailbox, no new tickets were created. After digging I have noticed an error in Service Desk Email Processor (which is a scheduled JIRA Job).
After turning on the debugging for incoming emails I have seen periodical errors in my Catalina.out file. Every error looked like this
2017-05-05 03:45:48,228 Caesium-1-3 ERROR ServiceRunner [c.a.m.incoming.jepp.processor] MailJobRunner Failed java.lang.RuntimeException: Unable to read next message at com.atlassian.jira.internal.mail.processor.feature.puller.mailitem.streaming.MailItemDTOIterator.next(MailItemDTOIterator.java:51) at com.atlassian.jira.internal.mail.processor.feature.puller.mailitem.streaming.MailItemDTOIterator.next(MailItemDTOIterator.java:15) at com.atlassian.jira.internal.mail.processor.feature.processor.MailProcessorWorker.process(MailProcessorWorker.java:75) at com.atlassian.jira.internal.mail.processor.feature.processor.MailProcessorService.run(MailProcessorService.java:36) at com.atlassian.jira.internal.mail.processor.services.MailProcessorExecutor.run(MailProcessorExecutor.java:30) at com.atlassian.jira.internal.mail.processor.services.AbstractMailExecutor.execute(AbstractMailExecutor.java:42) at com.atlassian.jira.internal.mail.processor.services.MailJobRunner.runJob(MailJobRunner.java:35) at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:153) at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:118) at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:97) at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:401) at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJob(CaesiumSchedulerService.java:396) at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:349) at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService$1.consume(CaesiumSchedulerService.java:255) at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService$1.consume(CaesiumSchedulerService.java:252) at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:65) at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:59) at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:34) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: invalid characters encountered in base64 data at org.bouncycastle.util.encoders.Base64Encoder.decode(Unknown Source) at com.atlassian.jira.internal.mail.processor.feature.puller.mailitem.streaming.MailItemTupleConsumer.decodeChunk(MailItemTupleConsumer.java:82) at com.atlassian.jira.internal.mail.processor.feature.puller.mailitem.streaming.MailItemTupleConsumer.consumeRow(MailItemTupleConsumer.java:65) at com.atlassian.jira.internal.mail.processor.feature.puller.mailitem.streaming.MailItemDTOIterator.readNextMessageFully(MailItemDTOIterator.java:71) at com.atlassian.jira.internal.mail.processor.feature.puller.mailitem.streaming.MailItemDTOIterator.next(MailItemDTOIterator.java:47)
Resolution
- remove the email channel from Service Desk project which generates the error
- create email channel with exact same configuration (email address, port, address etc)
Why it resolves the problem
When Service Desk administrator creates an email configuration it creates a new entry in the database and all pulled emails are identified by the email channel by its database id. Removing and creating new email channel, even if it connect to the same mailbox, will create a new entry and assigns new database id. In effect, every pulled email is identified by new mail channel id.If JIRA stored emails in the database which were not processed and the mail channel configuration were removed, the emails in the database were orphaned and will not be reused again.
If JIRA stored emails in the database which were not processed and in the meantime, the mail channel configuration was removed, the emails in the database were orphaned and left in status NEW. Mail channels are not reusable, hence all orphaned emails are redundant.
Hi,
Thank you for raising and watching this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request.
This is an automated update triggered by low engagement with this suggestion (number of votes, number of watchers).
We hope you will appreciate our candid communication and our attempts to become more transparent about our priorities. You can read more about our approach to highly voted suggestions here, and how we prioritise what to implement here.
To learn more about our recent investments in Jira Service Management and Data Center, please check our public roadmap and our two dashboards containing recently resolved issues, and current work and future plans.
Regards,
Charlie
Jira Service Management, Server & Data Center