JEMH: Map priority values not matching Jira default values

[Christian Schlaefcke]

Hi,

I am trying to share issues between JIRA and another incident management system (OTRS) and found using JEMH might be a good idea. General setup is working already and mails from on system to the other triggers issue/ticket creation quite well.

Now I need to fetch fields and values from OTRS and map them to specific JIRA fields - for example: priority. The good news: both systems provide a field named "priority". The bad news: The fields contain incompatible values. In JIRA we have Blocker, Critical, Major, Minor, Trivial and in OTRS I found 1_very_high, 2_high, 3_normal.

I searched the profile/field processer configuration and even found the regex fp which looks promising. It seem to work for complex matching tasks but I cannot see how it can be used to map incoming/incompatible values to existing JIRA values.

Basically I would need to map the incoming values of OTRS priority like this:

3_normal => Minor

2_high => Major

1_very_high => Critical

Any hint about how I can achieve this mapping is very much appreciated!

Best Regards,

Christian

[Andy Brook [Plugin People] · Accepted solution]

Hi Christian,

So, you say 'field' which I understand as structured text within the email body. If the delivered content, post conversion to text does not fall into one of the standard JEMH formats, then, you'll need to use the Regexp Field Processor to pull out the remote values. The sequence is:

1. Use Regexp Field Processor to extract the value content, eg 3_normal.

2. In the Regexp Field Processor, map a field 'priority' to that value (see supported fields). Of course, the value 3_normal doesnt map, thats where:

3. Use JEMH Aliases to Alias an externally supplied value to an internal JIRA value. So you would setup:

3_normal = Minor

2_high = Major

1_very_high = Critical

4. Enable Directives for Create at least.

This will result in the priority being set. Some additional 'hints' using the Regexp Field Processor, in order to map content to the 'description' during create and a 'comment' during comment, always set the directive 'comment' with your main ticket payload if there is one.

[Christian Schlaefcke]

I tried to configure what you suggested but still getting this processing hint:

Here is what I have configured so far:

Can you find something obvious?

Best Regards,

Christian

[Andy Brook [Plugin People]]

It all looks good, log a supoprt ticket, supply profile XML and your inbound test case, I'll take a look: https://thepluginpeople.atlassian.net/browse/JEMH

[Christian Schlaefcke]

Thank you for your support so far. I just opened JEMH-2571 for you.

[Andy Brook]

For anyone with this, two problems, the regexp field processor has an address, this should match the sender if not, the 'results' of a JEMH Test Case will indicate another processor instead, perhaps Basic. Second issue was if the format happened to match another processor (eg Colon Suffix format) then that processor would have claimed the message. As Regexp FP matching should superceed content matching for ownership of messages, in 1.5.90, regexp will boost its own claim to such messages, allowing all field processors to still be active.

[Andy Brook [Plugin People]]

For anyone with this, two problems, the regexp field processor has an address, this should match the sender if not, the 'results' of a JEMH Test Case will indicate another processor instead, perhaps Basic. Second issue was if the format happened to match another processor (eg Colon Suffix format) then that processor would have claimed the message. As Regexp FP matching should superceed content matching for ownership of messages, in 1.5.90, regexp will boost its own claim to such messages, allowing all field processors to still be active.