High speed issue linking in Jira Service Desk
This is the third in our Incident Management blog series, aimed at making your Incident resolution quicker and your customers happier. This time we look at how you can link your Incidents, Alerts and Remedial Actions to current and recent Problems, using a self-referencing transition in your workflow.
This instalment covers linking related Issues together for better diagnostics and management.
In order to create this functionality, we need to reuse some of the configurations that we built in the previous two articles. Let's quickly recap on what we covered in these two articles and what we'll reuse.
In the first blog, we created new Issuetypes and established appropriate links between them. We'll be using both the Issuetypes and links for this functionality.
In the second blog we saw how we could use JQL to find unresolved and recently-resolved problems. We will be reusing the following JQL to restrict our selection to current and recent Problem Issuetypes.
Note: If you've given different names to your Issuetypes or links, you will need to update the code that follows to match.
What linking achieves
Linking related Issues together is a powerful feature of Jira which allows you to better diagnose Issues and manage your work. If you're a frequent Jira user, you would have likely linked Issues before and have probably found it to be manual and labour-intensive. A process that requires you to know exactly what Issues should be linked and to manually complete forms.
What if we could speed up this process and reduce the potential for Issues to be missed or incorrectly connected?
Linking the problem ticket
The first step in linking tickets is to create a custom field. This custom field needs to be set as a Hideable Text Field and labeled as "Known Problem". To build this Hideable Text Field select the <255 characters option in the Advanced Select Field Type. We're selecting this option as we only need to store the Problem Issue key in the field which should never be anywhere near 255 characters in length.
Next, we want to make sure that this field is only available for the following Issuetypes Incident, Alert, Remedial Action. This means that we need to set the configuration to only these three Issuetypes. At this stage, we could also restrict this functionality to certain projects but for this example, we're only restricting our use of the Issuetypes with an Issuetype Scheme at the project level.
Now we have the custom field, we will create a screen called “Link to recent Problem” that we can use on the transition. For this screen, we are going to keep the information requested to the Known Problem field that we have just created and of course the standard comment field.
Updating your workflow
After we've added our screen, the next step is to edit the workflow(s) that are associated with the Issuetypes Incident, Alert, and Remedial Action. We're going to use a little-known but powerful piece of functionality, the ability for a workflow to transition from any status back to the same status. While adding a circular workflow sounds rather odd, critically it allows us to add a transition and where you have a transition you can add a transition screen and post-function. This appears on the workflow diagram as shown.
Creating a transition
So let's look at the steps to create this transition. First, we'll add a transition and fill in the options as shown below.
Note: The two status fields use special values that don't refer to the single status.
After that, we need to add the following condition to the workflow to make sure this is only available for the appropriate Issuetypes.
We could also add a property to the transition to place the transition as the first option.
The final step in the workflow stage is to publish it. Once we've done this, remember to check that the right screen loads on the transition.
Our next step is to add the behaviour to our new field so that it only offers the choices from current or recent Problems. In order to add the behaviour navigate to:
Select create a new behaviour and give your new behaviour the following name and description:
Then map the following fields:
Next, add an initialiser function with the following code. This initialiser function will be called whenever the field is presented on a screen for editing.
url : getBaseUrl() + "/rest/scriptrunner-Jira/latest/issue/picker",
query: true, // keep going back to the sever for each keystroke
// this information is passed to the server with each keystroke
currentJql: "issuetype=Problem AND (resolution is EMPTY OR resolutiondate > -7d) ORDER BY resolution, key ASC",
label : "Pick from Open or Recent Problems",
// specify maximum number of issues to display, defaults to 10
//Specify css for the size of the dropdown maximum width
css: "max-width: 500px; width: 500px",
Lastly, place a listener on the custom field in order to make sure that whenever a value is entered the links on the issue are updated to include the related Problem.
Testing the link
You should now test that your system is working and that when a new Known Problem is associated with an Incident, Alert or Remedial Action the Issue links are updated correctly.
Once it is, you'll be able to group your incidents with much more ease, increasing your diagnostic abilities and allowing for better organisation of your Triage.
Our next tip looks at how we can quickly create a new problem ticket from inside an Incident or Alert. To find out more about how ScriptRunner for Jira can help you extend, automate, and customise your Jira instance, start a free 30 day trial on the Atlassian Marketplace.