Can JEMH provide a custom 'gadget' for issue screens which provides the facility to send an email to the reporter

I would like the Issue screens to have a button / widget to allow the person viewing the issue to communicate with the reporter, rather than have the notifications being sent to the reporter.

This would be a great feature which could enhance JIRA when used as a Service Desk tool - particularly when communicating with non JIRA users.

Could this feature be provided as part of the JEMH plugin?

3 answers

1 accepted

0 votes
Answer accepted

Hi Andy,

What I was thinking about was a facility to email the email-reporter (which would need to be stored as a custom field for non-JIRA users) and append the email contents to the Comments section to ensure all communications are captured.

My idea was to have a plain HTML form overlay using Ajax to access the REST API to both send the email (notify) and append to the Issue comments. The HTML link or button to activate it could be implemented as web panel, with the associated form and JS bundled with it.


non-jira email users emails can already be saved to a CF, I take it this popup would send only to the non-jira user? JEMH currently has its IssueListener, so the act of you commenting on the issue can already result in that remote user receiving an email. The fun starts when the remote user adds a bunch of other non-jira users as cc: , those users currently get their emails also stored in the CF and are also get notified through JEMH IssueListener.

So, if JEMH IssueListener wasn't used, I can see some need, but largely, doesnt just commenting and using the IssueLsitener for notifications achieve this? OK, if you just want a remote user to receive a specific bit of info, fine, that can be done.

I've linked to this question, I will see if I can add something here following the 1.3 release.

I am already saving the email address to a CF. Good point about CC'ing.

What I would like to avoid is the non-JIRA users seeing all the comment changes on an issue while it is being handled by the help desk agents.


OK, So there are a couple of things you can do.

1. Dont send issue commented events, just disable ISSUE_COMMENTED events from firing, of course the question is then, how to converse with the user?

2. Comment visibility. Users can comment on the issue via JIRA, and set comment visibility. There is a flag on the JEMH IssueEvent listener that will cause comments with any kind of visibility to be blocked.

JEMH also can set a default comment visibility so any email comments received is tagged with specific visibility.

Unfortunately, there is no in-build JIRA mechanism for setting a default comment visibility. It could well be possible with some javascript tweaking via Jamie Echlin's Behaviours plugin.

I think the ideal would be to have 1, avoiding are unexpected comments getting out, and having a specific button in the UI to notify the user directly, possibly having that even locked to a specific customer-relations group. I did hear of one case where this was done but I haven't documented it as yet. JEMH work to date has been mostly on the backend, addressing features like this are on my near term roadmap.

Hi John, I may well opt for a quick win though a 1.3.x release to address this kind of need, I can see the benefit. I'm just doing last minute validation of 1.3, which I hope to complete today and am relocating to UK next week, guess within 6weeks for such a feature.

Hi Andy, do you have timeline for Version 1.4



To bring this question up to date, JEMH 1.5.22 (JIRA6.1+) now has an Ad-Hoc notification popup feature that can be driven by custom fields for email addresses (in addition to Workflow Postfunction achieving the same). It also integrates with JEMH AdHoc TemplateSets allowing canned responses.

Hi John,

You say 'communicate with the reporter' but rather than via notifications, so are you asking for an out-of-issue ad hoc notification (email?) or other kind of transport? Can you ellaborate, how is the reporter to receive the communication, and especially if that user is a non-jira user?

JEMH features to date have been mostly focussed on the backend configuration features, (next 1.3 release gets LDAP and the start of pluggable API's), the UI does need to get some TLC.

I want to improve the user UI and such features will be in upcoming releases. More 'enabling' features will be coming in 1.4, with API's for additional 'transports' that could well be the vehicle for out-of-issue communication you mention.

I'm more than happy to get new feature requests on my shiny new OnDemand instance @

Hi Andy,

Kind of similar to John, I have a need to use JEMH in a Helpdesk environment where I want agents to be able to conduct an issue dialogue via email that is not visible to the end user, but at the same time be able to conduct a customer dialogue - kind of like 2 parallel comment streams - one restricted, one unrestricted. All end users have a JIRA account. I had envisaged setting up a custom field that is made invisible to the end-user via role controls, but do not see a JIRA field type that allows appending. Do you know of any workarounds?



Suggest an answer

Log in or Sign up to answer
Community showcase
Published Wednesday in Marketplace Apps

Marketplace Spotlight: Marketing apps for Confluence to keep your teams working on the same page


189 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you