Who doesn’t like Jelly?

At work we have some SOC2 fun stuff to attend to, one of the areas that I’m looking at is incident management, we’ve been doing incident management and analysis of incidents for a while so this was really about formalising it all. We use a highly customisable ticketing system called Jira which is good at its job although getting to grips with its configuration can be tricky.

One of the areas we have to ensure process is followed is with escalation of incident tickets, our incident tickets are identified with an issue type of “Incident” and we have a special “incident priority” field which is simple P1, P2 or P3

So the challenge for us was how do we make sure that each tier of escalation gets notified and that it is clearly documented the ticket has been escalated?

This is where Jelly comes in, Jira has Jelly which is an XML defined way of doing programatic actions within Jira, a good link to open and read later will be this one all about Jira:Jelly and if like me who only found it afterwards these will be useful docs for Jelly: email http SOAP SQL core

Defining Filters

To get the escalations to work I used filters to show me all tickets that matched a certain pattern, so to do the first tier of escalation the filter looks for all tickets in the project and that are of the issue type “incident” and have an incident priority of “P1” and are older than X mins. To stop this coming up more than once the filter was also given some extra parameters to only show when it wasn’t assigned to the current escalation person or one of the higher up escalations. If it was assigned to anyone else it would then be escalated.

project = PROJECTID AND issuetype = Incident AND
status in (Open, "In Progress", Reopened) AND
"Incident Priority" = P1 AND created <= -30m AND
assignee not in (escalation1, escalation2, escalation3)

I won’t explain this too much, but “PROJECTID” will be the short code for the project in jira, and the escalations at the end are the usernames of those in the escalation tiers.

Here’s tier 2 as well so you can see how it filters for the next tier:

project = PROJECTID AND issuetype = Incident AND
status in (Open, "In Progress", Reopened) AND
"Incident Priority" = P1 AND created <= -45m AND
assignee in (escalation1) AND
assignee not in (escalation2, escalation3)

and the third for completeness:

project = PROJECTID AND issuetype = Incident AND
status in (Open, "In Progress", Reopened) AND
"Incident Priority" = P1 AND created <= -75m AND
assignee in (escalation2) AND assignee not in (escalation3)

As long as “assignee in” has the person of the previous tier in it and the “assignee not in” has those still left to be assigned to it should work okay…

All these filters do is show tickets at various stages of the escalation process, because of that it is possible to associate that with a jira jelly script to actually carry out actions on it.

Jira Jelly

Remember that link earlier? the one to the Jelly page? well that will help with the others above… Now you need to know what to do.

You have a way of filtering out the tickets so you can now write a script to do something at each stage of the escalation as needed. In our case we need to maker sure the user receives a notification and that a comment appears in the ticket so it is clear it has been updated.

The first attempt of this was to simply add a comment with the newish @user mentioning system which then automatically lets the user know they were mentioned. Unfortunately when using the add comment method it simply puts this in as text and when expanding the short hand to the full [~user] it just entered as text which means this method was not viable for us so instead we just simply assigned the ticket which has the affect of also adding the person to the watchers.

To do this sensibly it requires a few steps, a Login, the use of the filter to find the relavent tickets, a comment added and an assignment to happen.

<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib" xmlns:core="jelly:core" xmlns:log="jelly:log" >
  <log:info>Running 'Escalation for Incidents - t1' service</log:info>
  <jira:Login username="escalationuser" password="XXXXXXX">
    <!--  Escalation People -->
    <core:set var="escalate" value="escalation1" />
    <!-- Run the SearchRequestFilter Filter is Open PROJECTID P1's-->
    <jira:RunSearchRequest filterid="FILTERID" var="issues" />
    <core:forEach var="issue" items="${issues}">
      <log:warn>Escalating ${issue.key}</log:warn>
      <jira:AssignIssue key="${issue.key}" assignee="${escalate}"/>
      <jira:AddComment issue-key="${issue.key}" comment="Escalating to ${escalate}"/>
    </core:forEach>
  </jira:Login>
</JiraJelly>

The filterid can be found by simply viewing the filter and copying the number from the end of the URL, hopefully everything else is self explanatory. for each escalation simply copy the file, update the filter ID and the escalation user

Install

1, Copy files to the server and put somewhere sensible that tomcat has access too, ensure the files are owned by tomcat and that tomcat can write to that directory.
2, In Jira, go to Administration -> System -> Advanced -> Services and add a new service, give it a name and select the built in jelly runner. Enter the location of the script and provide a log location.

That’s it. I noticed that having server access was invaluable, mainly because I was using VI and some syntax errors made it in which were hard to spot with out seeing the log, you can test your scripts using the Jelly runner which is also useful.

In short that’s it, hopefully that will be useful for people :)