Integrating Jira with another Ticketing-System via JEMH

Alexander Suelb

Hi!

We would like to use JEMH to, in a first approach, connect an internal Ticketing-System to several Jira projects. I am researching the following questions, maybe you can provide us with some answers.

We use Jira 6.1.6 and receive incoming mails through one account. Currently mails from the ticketing system arrive in a subfolder of this account that we can query with jira. It's always the same sender address.

a) The related ticket ID is in the subject of the mail (long integer, should go to custom field), also information about the status (like “to be processed") that should be used to update or close an issue later on

b) The Body is HTML and contains several links. The one that starts with https://ticket.abc-... should be extracted, if possible, and added to a custom field in the jira issue

c) The Body also contains more keywords (…under category “xxxxxyyyyy” -“longdescription" in the Ticketsystem ...) that should be integrated into custom fields

d) One of the keywords in the body should be used to distinguish the Jira project to use for the issue

e) The message has a certain urgency that relates to the priority of the issue

f) A custom text should be added to the issue as a comment depending on what is done, at least when it is created

g) The html should either be included or better converted to text only (if possible)

h) Notifications should be sent to several people on touching/creating an issue

i) Roles like "watcher", "reporter" and "assigned to" should be set during the creation of a new issue

j) It should be possible to use this within our own workflow in this project (only open and resolved status known known)

k) Roles like "watcher", "reporter" and "assigned to" should be set during the creation of a new issue depending on the actual project the external ticket goes to.

If all of these things are even possible with the combination of Jira and JEMH, can a Jira admin set this up in a given period of time? Is there enough documentation about JEMH that gives us hints on where to configure what we want to do?

Thanks a lot and regards,

Alexander

unknown

A great question, I'll do my best to answer, Im afraid my response will be limited in length, you ask for too much detail, try JIRA if you need more - https://thepluginpeople.atlassian.net/browse/JEMH

We use Jira 6.1.6 and receive incoming mails through one account. Currently mails from the ticketing system arrive in a subfolder of this account that we can query with jira. It's always the same sender address.

Fine, but be aware that mail servers limit the concurrent use of a common mailbox. This matters if you expect to have more than, oh, 15 or 20 folders.

a) The related ticket ID is in the subject of the mail (long integer, should go to custom field), also information about the status (like “to be processed") that should be used to update or close an issue later on

Yes, JEMH has a Regexp Field Processor written to run targetted regular expressions on content, and can use such a remote ticket ID identifier in the subject, storing it in a custom field. If no issue exists with that custom field value, its created, subsequent ones are added as comments to the original issue. https://thepluginpeople.atlassian.net/wiki/display/JEMH/Use+Regexp+Field+Processor

Depending on exact nature of text, some workflow advances are possible, they need to be a valid next-transition for the current issue state. The appraoch is to use JEMH Aliases to translate remote vocabulary to JIRA specific terms ( in this case to define a value for 'workflow' such that the key 'to be processed' mean to JIRA 'start progress' or similar). https://thepluginpeople.atlassian.net/wiki/display/JEMH/Use+Aliases

b) The Body is HTML and contains several links. The one that starts withhttps://ticket.abc-... should be extracted, if possible, and added to a custom field in the jira issue

Using the Regexp Field Processor against structured content, its possible extract lots of text and map them to custom fields. Such processing is done after HTML is converted to 'text' (though JEMH actually can convert to wiki markup, thereby retaining the in-comment link as well).

c) The Body also contains more keywords (…under category “xxxxxyyyyy” -“longdescription" in the Ticketsystem ...) that should be integrated into custom fields

Get you regular expressions hat, you'll need it. Many regexp can be defined to capture content in fields this way.

d) One of the keywords in the body should be used to distinguish the Jira project to use for the issue

Hmm. JEMH has keyword matching for projects but its done differently with Project Mappings, I did remember a similar question/issue recently, and may have already made this interoperation work, need to check. In theory yes, project mapping by subject (or body) keyword is possible. https://thepluginpeople.atlassian.net/wiki/display/JEMH/Use+Project+Mappings

e) The message has a certain urgency that relates to the priority of the issue

JEMH has limited support for elevating priority based on email priority, it could be imprpoved, needs a driving test case.

f) A custom text should be added to the issue as a comment depending on what is done, at least when it is created

By who, when, containing what? JEMH uses email 'content' or subset thereof for issue creation, it can prefix that content with some basic identifiers suchas email subject/to/cc/from. https://thepluginpeople.atlassian.net/wiki/display/JEMH/Customize+the+Comment+Header

g) The html should either be included or better converted to text only (if possible)

Email 'original' content can be attached in its transport state (unconverted by JEMH) so HTML will be loadable, or text. TEXT content tends to be much cutdown strucutrally if the sender created it in HTML. The sender may not send or include TEXT. The complete email can also be attached in its raw TEXT format, requiring a mail application to load it.

h) Notifications should be sent to several people on touching/creating an issue

JEMH has email transport notification support for non-JIRA users and JIRA users. As yet to go mainstream is support for other transports for those notifications (ie SMS, XMPP).

i) Roles like "watcher", "reporter" and "assigned to" should be set during the creation of a new issue

Yes, depending on defaults or project mappings.

j) It should be possible to use this within our own workflow in this project (only open and resolved status known known)

JEMH has a workflow postfunction for sending ad-hoc notifications that can be either static text or based on JEMH TemplateSets for customized content notification. The recipients can be manually entered or include the non-JIRA user custom fields as a source of email addresses. There are some limitations specific to the creation of the issue, but once created everthing will work as expected. https://thepluginpeople.atlassian.net/wiki/display/JEMH/Use+the+JEMH+Post+Function

k) If all of these things are even possible with the combination of Jira and JEMH, can a Jira admin set this up in a given period of time? Is there enough documentation about JEMH that gives us hints on where to configure what we want to do?

From what Ive seen above, there isn't anything JEMH+JIRA can't do! Your JIRA admin has access to the task centric documentaion @ https://thepluginpeople.atlassian.net/wiki/pages/viewpage.action?pageId=2850843. There is also a JIRA issue tracker where long queries like this one can be logged - https://thepluginpeople.atlassian.net/browse/JEMH