Skip to main content

How to add different description templates for different issue types using scriptrunner behaviours (Jira Cloud)

Hello All !

Recently I have been getting several requests from Jira project owners to setup default description templates for different issue types. In this blog post I will go over how to set up different description templates for different issue types using scriptrunner behaviour scripts for Jira cloud.

Writing a behaviour script in Jira cloud is very different compared to writing a behaviour script in Jira data center. Main difference is the language to use. With Jira data center you are limited to using Groovy and with Jira cloud you have the option of using Javascript or TypeScript. Also, below is another major difference with regards to the field that the script is attached to.

A fundamental difference between the ScriptRunner for Jira Server/DC and ScriptRunner for Jira Cloud behaviours feature is that the field selected is the trigger that causes the behaviour to run in ScriptRunner for Jira Server/DC. However, with ScriptRunner for Cloud, you choose an affected field first and then write a script with logic that will alter that field in your preferred way - adaptavist scriptrunner documentation.

Before we jump into creating behaviours, let's define our requirements and assumptions for this blog post. 

Requirements : 

  1. When a user selects the issue type "Story" in the project "Atlassian Tools Setup" create issue screen, below text template should be set in the description field.
  2. When a user selects the issue type "Bug" in the project "Atlassian Tools Setup" create issue screen, below text template should be set in the description field.
  3. When a user select an issue type other than "Story" or "Bug" in the project "Atlassian Tools Setup" create issue screen, the description field should be empty.
Assumptions : 
  1. Scriptrunner for Jira cloud and Scriptrunner Behaviours Forge app is installed on your Jira cloud instance.
Now that we have defined the requirements, let's see our solution design for this implementation.  

Given that Scriptrunner Behaviours Forge app is brand new, it has certain limitations. One of the limitations (as of writing this article) is listening to change of issue type on the create issue screen (if someone comes across this feature, please comment and I will update this post). Given this limitation we will have to create 3 different behaviours to satisfy the 3 requirements we have for this blog post. Two of these behaviours will set a description template for Story and Bug issue types and one will clear the description field if the issue type is Epic or Task.







Now let's go into each behaviour and see how they are setup.



Labels:

Comments

Post a Comment

Popular posts from this blog

How to send a survey with multiple questions in Jira Service Management (Jira Cloud & Jira Data Center)

Hello All, Out of the box Jira Service Management only allows to add one question for the customer satisfaction (CSAT) survey once a ticket is resolved. But most teams like to collect feedback on different aspects of the support provided to the customer by adding more than one question. In this blog I will go over a workaround to send multiple questions to the customer when a ticket is resolved.  Scenario Support team uses Jira Service Management to work on customer requests. Once a request is resolved an email needs to be sent to the customer with a survey including multiple questions. Survey response needs to be tied to the Jira ticket number. Solution In order to send multiple questions we will use a google form.  When the ticket is resolved the reporter will get an email with a link to a google form containing the survey questions.  The first field of the google form will contain (this will be autofilled) the issue key where the user received the survey. Given that we...
Post a Comment
Read more

How to export a list of Jira custom fields to csv (Jira Data Center)

 Hello All ! As a Jira administrator it is very important to keep an eye on the number of custom fields you have in your instance because the number of custom fields directly impact your instance performance. Atlassian also has confirmed this in their documentation .  One of the important strategies to keep your custom field number low is to reuse them as much as possible across projects. When you get a request from a user to create a custom project, you can provide a list of custom fields upfront, and ask the user to choose existing fields instead of creating new ones. Out of the box, Jira doesn't provide an easy way to export the custom field list to a csv file to share with non Jira admin users. In this blog I will share how I exported all Jira custom fields into a csv file using Jira REST API and Python. This solution was tested on Jira Data Center version 8.x, Python3 and Windows 11. Let's see how we can get the custom field list in 3 easy steps. Note : I assume that you...
Post a Comment
Read more

How to setup Jira SLAs for global teams across multiple time zones (Jira Cloud & Jira Data Center)

Hello All! Being a global company creates the need to have IT teams across different parts of the world in different time zones. When you have team members working in different time zones you also need the ability track SLAs for the work they do. In this blog I will go over a solution to track Jira request SLAs for global teams across multiple time zones. Scenario: IT department have three teams in three different time zones (Barcelona, New York,  Los Angeles).  Employee requests are processed by the IT team assigned to the location of the employee. All three IT teams work from 9:00 AM to 5:00 PM (Monday - Friday) in their respective time zones.  Every request submitted to IT needs to be resolved within 40 business hours.  Requests can be transferred to another team and the SLA clock should be updated to use the respective time zone of the teams location.  Office Location Timezone Hours (M-F) Time to resolution Barcelona CET 9:00 AM - 5:00 PM 40h New York EST 9:...
Post a Comment
Read more