Restricting Issue Types with ScriptRunner for Jira

Issue Types are a fundamental component of Jira. They are entities that represent tasks, product bugs, feature requests, user stories and any other key elements of your project. Issue Types often come with their own predetermined set of fields, following a predefined workflow. To save valuable time and resources and avoid frustrating everyone involved in your project, its critical to ensure the appropriate Issue Types are always selected from the outset.

The problem

It’s a conundrum that most Jira users have encountered at some point in a project. Selecting the wrong Issue Type in Jira has two consequences. Firstly, poor classification creates fields and workflows that may not be suited for the task-at-hand, resulting in a user having to go back and spend precious time reclassifying them. Secondly, if the wrong workflow is triggered due to inaccurate classification then the wrong team could be alerted, resulting in even more time lost re-assigning to the correct team.

With speed and efficiency being paramount for today’s businesses there is a lot of emphasis placed on streamlining workflows and making sure that the right information reaches the right person on time.

With that being said, wouldn’t it be great if you could limit the Issue types that a user could create to avoid poor classification altogether?

The solution

The solution is within the Behaviour functionality. Behaviours define how fields behave for issues in a given project or issue context. For example, making a field read-only dependent on user role or group, or setting a field value dependent on other issue screen data.

With the release of ScriptRunner version 5.4.38 we introduced the ability to restrict the available Issue Types that a user can select from, using these very Behaviour functionalities.

The use case and implementation

Let’s see how this could work in practice. Say you have a project that has the following Issue Types:

• Bug
• Task
• New Feature
• Query
• General Request
  

The permission scheme for this Project allows any logged in user to create Issues. As an admin you would like certain groups of people to only have access to a subset of Issue Types to select from, when they raise issues for that project.

As we already mentioned we are going to need to configure a ScriptRunner Behaviour. Al we have to do is to add the following script as an Initialiser.

Now with the above script being active, the following four scenarios are possible:

• The current user belongs only to the Users group, therefore the only available Issue Types to select from are: Query and General Request.
  
  

• The current user belongs only to the Developers group, therefore the only available Issue Types to select from are: Bug, Task and New Feature.
  
  
  
  
• The current user belongs to both the Users and Developers groups, therefore all of the above sets of Issue Types (Query, General Request, Bug, Task and New Feature) are available.
  
  
  
• The current user doesn’t belong to either the Users or Developers groups, therefore he is prevented from selecting any Issue Type for the particular project.
  
  

Limitations

Behaviours are a fantastic functionality within Jira, however, they do have some limitations. Behaviours rely on client-side javascript. In most environments users are free to disable javascript in their browser. If security of a field is critical, behaviours alone won’t be enough to protect it from malicious data entry (in our example select any Issue Type).

In that case you could back up the behaviour with a ScriptRunner validator. 

Gone are the days of losing time reclassifying Issue Types. ScriptRunner ’s customisation features allow the user to solve the challenges associated with Issue Type classification in Jira. With some simple upfront visual customisations you can improve accuracy, efficiency and make everyone’s life easier. Save yourself a headache and let ScriptRunner restrict save you time so that you focus on the stuff that really matters.