nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Emailing Customers External to JIRA

Lathrop [PSU]

I'm interested to hear about what anyone else is using to email customers who are not internal JIRA users. We have looked at listeners, mail handlers, and plug-ins but are not having much success. We just tested the Email this Issue plug-in which gives us some basic functionality that we like but just doesn't gel with what we would like to see ultimately. We are using JEMH for incoming mail and are very happy with it, but it doesn't seem to have the ability to sent mail externally. ( I might be missing a configuration though, I'm pretty new to this.)

What are you all using? Suggestions?

Thank You!

Accepted answers

Sundale IT

We have Active Directory/LDAP integration which I believe would eliminate some of your issues. Alternatively define project roles back to a distribution list. Within our environment, all external customers are setup as Contacts within AD sitting within an appropriate OU (usually mapping to a DL especially for projects). We then have the added advantage of LDAP synchronisation which then presents them as an option of assignee, watchers or can be used as within scripts etc.

This has the added advantage of received email on a distribution list is pushing to a mailbox and can also be filtered back into JIRA with assignments to users and contacts.

We also use and endorse 'Email this' with an updated Velocity template. +1 also for PDF View in these scenarios

All comments

Radu Dumitriu

[Again, I need to praise myself]

For JJUPIN plugin, we developed a mail template mechanism. We had a similar problem, so we decided to give it a go like below.

Let me give you an example, a post-function which sends emails (the SIL script):

string [] #{to} = #{customfield_10011};
string #{subject} = "Xmas";
string #{body} = "template.tpl";
string #{cookie} = "We have cookies!";
sendEmail(#{to}, #{subject}, #{body});

and the template will contain (template.tpl, placesd in a special directory on the disk):
---------------
Hello $recipient$,

This is a test template sent from $assignee$'s issue $key$. The summary for this issue is: $summary$.

$%key%.assignee$ says that $cookie$

---------------

In this way, we expose each variable from our script (see the 'cookie' variable) including the standard and custom fields, into the mail body so you can do on your postfunctions pretty much everything.

It's funny, really.

Lathrop [PSU]

We will definately look into this. If we have questions, is it ok to contact you?

Radu Dumitriu

Sure, no probs

Sundale IT

This has the added advantage of received email on a distribution list is pushing to a mailbox and can also be filtered back into JIRA with assignments to users and contacts.

We also use and endorse 'Email this' with an updated Velocity template. +1 also for PDF View in these scenarios

unknown

JEMH can provide a single 'issue created' email, which is done outside the normal Jira notification processes. This is specifically to handle scenarios where you dont want/cant create users for every inbound email. JEMH allows you to store the sender email address, but that is where its functionality stops. Where you don't have 'real' JIRA users who can login and use the system, you'd need to write a listener to check for that value and email something.

If you are willing to configure user auto-creation, so long as those users don't get 'jira-users' (ie they cannot login) I believe that the normal Jira notification schemes apply.

If you are after a specific feature, please raise it in the JEMH JIRA project.

I'm working on a UI for JEMH, so if you envisge being able to configure such things via screen, feel free to log it at https://jemhui.brightidea.com/ideas .

Lathrop [PSU]

Thank you for your comment. We are going to continue to use the Email this Issue for now. Later we might move to the JEMH for this but that requires some changes to our organization.

Lathrop [PSU]

Thank you for your post. In order to use the JEMH this way we would have to change the way we are handling users. While this is a good idea we aren't currently set up to make the switch. We are planning the transition though. Thanks again for the information.