I am using the Jira Service Management integration for OpsGenie. In my Jira instance, I have the Jira priority values (Blocker-High-Medium-Low) mapped to OpsGenie priority values (P1-P2-P3-P4).
When using this rule, the priority mapping works fine: ELSE IF eventType equals issue_created THEN create alert
In Jira Service Management, I have Automation rules to set the priority based on Impact and SLA Tier. To give these Automation rules time to run, I use the issue_updated eventType in OpsGenie instead:
ELSE IF eventType equals issue_updated AND labels contains headless_incident THEN create alert
However, when using this rule, although the priority value in "Extra Properties" is Blocker, the priority is set to P3 and not P1.
I could hack around this by creating multiple rules to set the priority manually, but it would be nicer just to use the {{priority}} dynamic value in a single rule.
Any ideas?
Hi @Michael.Gaskin ,
I don't think the filter being different would cause an issue. Normally, if you're using the mapped priorities, when it reaches Opsgenie you need a number to extract. For example:
P{{impact.extract(/[0-9]/) }}
The fact that the alert is showing "Blocker" in the priority field likely means that the mapping could not process anything into a valid Opsgenie priority of P1-P5.
Can you post what is in your Mapped Priority Value field in Opsgenie?
Hi @John M
I worked on it more last night and found that the rules are indeed a red herring; what's really happening is:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Michael.Gaskin can you verify that the issue type for the issue(s) that are not working are 'incident'? The mapping only works for issues with a type of 'incident'
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.