Is the "Mail @ Issue" jira application dead?

[Peter Hostačný]

I am writing this post for a second time because this "Ask a question" form is really bad and after I clicked publish - it seems to have just thrown away my question.

Therefore I am not going to spend the time again by writing all the details I did before.

I will simply ask - is this application dead or does Attlasian plan to fix it?
https://marketplace.atlassian.com/apps/1219929/mail-issue-send-email-to-issue?hosting=cloud&tab=support

It does not work. Support link leads to an error. Documentation link leads to an error. The feature looks to be a basic functionality that should be supported natively - not having it makes JIRA behind Trello that supports this feature out of the box for free.

[Matthias Gaiser _K15t_]

Hey @Peter Hostačný

welcome to the Atlassian Community. The app you've mentioned is not developed by Atlassian themselves, but by the marketplace partner Atlas Cloudlet.

I was also unable to find documentation or anything online about the company - I wouldn't trust too much into the app right now.

There are multiple other apps in the marketplace which extend Jira with email functionality. Would one of them work for you?

Cheers,
Matthias.

[Peter Hostačný]

I am not able to uninstall this app. I have cancelled the trial and now it's pending. Why would Attlasian not allow third party app uninstallation?

[Peter Hostačný]

@Matthias Gaiser _K15t_ thanks for the suggestion but I simply need a way to put the issue into "CC" so the email thread gets attached and also all the following replies. Does any of the apps support this functionality?

[Matthias Gaiser _K15t_]

Yeah, I think you have to wait until the trial is over and then you can uninstall the app. I also don't understand why.

[Matthias Gaiser _K15t_]

@Peter Hostačný I'm no expert in these apps, but I've found this page in the docs of Email This Issue which covers maintaining email chains.

If someone else has more ideas around it - please jump in.

[Peter Hostačný]

Appreciate you checking this out for us, @Matthias Gaiser _K15t_  From what I can tell, this app mainly handles sending emails from Jira, not receiving them. The pricing also seems a bit steep for our current needs.
The functionality does look valuable, and we might explore it down the line - but right now we’re specifically trying to find a way to get incoming emails into Jira and attach them to issues.

[Andrea Rákosfalvy _META-INF_]

Hi @Peter Hostačný ,

Andrea, from Email This Issue support here (thanks for suggesting our app @Matthias Gaiser _K15t_ I would jump in here to clarify that we do handle both inbound and outbound email communication.

For maintaining email chains, we use message IDs in email headers - the IDs for incoming emails are associated with the issue, and the IDs of emails that we send from a particular issue. If anyone replies to either of these emails, the incoming mail handler "Lookup by mail header" rule allows us to find the issue that the original email is related to, even if the issue key is not in the subject of the email (which is our default search method).

We also display all emails related to the issue on an "Emails" tab, and you can reply to emails directly from there, retaining the full message history. Other options for outgoing emails include notifications, workflow post functions, in which case you can add for example all public comments from the ticket to have a conversation history element in the email.

Feel free to contact our support team to request a demo to see the full capabilities of the Email This Issue app.

[Peter Hostačný]

Hi @Andrea Rákosfalvy _META-INF_ , thanks for the detailed reply and the demo offer.

At the moment, we're not looking for a solution focused on outgoing emails. Our primary need is inbound email handling, ideally with a unique, randomized email address per issue, so that messages can't be linked to issues just by guessing IDs or altering email addresses.

The email threads we want to ingest into Jira would not be initiated by your app/plugin. These might be external conversations already in progress, and the only change would be that someone includes the issue-specific email address in CC - which should then route the email into the correct Jira issue. Or a brand new email that is forwarded into the jira specific email address.

Does your app support this kind of workflow?

Thanks again!

[Andrea Rákosfalvy _META-INF_]

Hi @Peter Hostačný ,

Sounds doable, as we also have JQL lookup rules. :)

There needs to be an incoming mail server that you can link up to the Email This Issue app (we cannot access emails that go to the mail address Jira gives you).

The issue-specific email address should be saved on the issue somewhere, either a custom field, or the mail address needs to contain something that we can extract with a regular expression and use in a JQL where the issue is the top match.

For example:
email address: 1a2b3c@company.com

custom field: 1a2b3c

The find issue lookup rule would look like this:

The lookup by issue key rule in our app is always active, so the scenario of guessing the key still needs to be handled separately. For this there are several options in the mail handler actions themselves using conditions.

You can have a condition that checks that the sender has access to the issue (is the reporter, or a request participant, or a JSM team member etc), or repeat a check that the custom field matches the TO or one of the CC addresses - only if the condition is true, should a comment be added or any other issue action performed. Otherwise, the email will just be discarded.

Here it is important to note that for an email to appear on the issue's email tab, the handler must take some action with it (add comment, update a field, perform a transition) - if the handler doesn't do anything, the email will not show up on the emails tab either.

[Peter Hostačný]

@Andrea Rákosfalvy _META-INF_ 

Thanks for the detailed explanation - I really appreciate you taking the time to walk through how this could work.

That said, I’m a bit concerned about the requirement to maintain a separate mail server, which adds operational complexity and potential risk on our side. Also, given the price point of the app, we were hoping for something that feels more built-in and doesn’t rely on external infrastructure.

We may still consider it, but at the moment this seems a bit heavier than what we were hoping for. To me it does not feel like it would be worth the price.