By Alan Reynolds, RightStar Systems
Many of you may be using Riada’s “Insight – Asset Management for Jira” app from the Atlassian Marketplace to manage Configuration Items in your CMDB, but have you considered using Insight for other purposes, such as to store your Incident categorizations?
One big advantage of this approach is that the maintenance of categorization values can be assigned to a non-admin Jira user. If these drop-down list values were implemented as standard Jira fields, a Jira administrator would be needed to make any updates to the list of categorizations. Storing these categorization lists in Insight allows the administration to be delegated to any appropriate resource since permissions can be assigned per Object Schema in Insight.
Additionally, issue categorizations often need to be 3-tier structures, and sometimes even larger. However, using standard Jira fields only a 2-tier menu-structure using the ‘Select List (cascading)’ field type is possible. There is no support for a 3-tier menu structure using standard Jira fields, although there are feature requests for this for both Server (https://jira.atlassian.com/browse/JRASERVER-7936) and Cloud (https://jira.atlassian.com/browse/JRACLOUD-7936).
Ready to give it a try? Here’s one way you might go about it.
Create a new Object Schema to store this meta data. I’ve called mine “Jira Metadata”. It stores foundational data in my system which I use in my Jira Service Desk projects for things like billing codes, accounting codes, vendor names, manufacturer names, etc. In this case it will be my tiered classification structure for my Incident, Service Request, Problem, and Change issues.
Create new Object Types in the metadata Object Schema, one for each tier in the categorization structure. In my case, I’d like a 3-tier structure (Categorization Tier 1, Categorization Tier 2, Categorization Tier 3) to use on my Jira forms, so I’ve created three Object Types. But I might want to support various categorization structures on different screens, so I’ve also added a “meta-tier” above these called Issue Categorization Type.
Create at least one Issue Categorization Type. In my case, I created four which will be used for different purposes. For this Object Type, no custom attributes needed to be added since the only thing that needs to be stored here is the name of the type of categorization. I used the system ‘Name’ field for this.
Create some Issue Category Tier 1 objects. These will be the first level of the categorization, so these are typically fairly broad.
In this Object Type, I added two custom attributes:
1. Categorization Type
This attribute stores a reference to an Issue Categorization Type (the one in step 3), using a custom reference type I created called “Categorization”.
2. Categorization ID
This attribute stores an arbitrary ID I created to uniquely identify the Categorization Type.
Create some Issue Category Tier 2 objects. These will be the second level of the categorization, so these are typically more specific than the first level.
In this Object Type, I added only one custom attribute, called Tier 1. This attribute stores a reference to an Issue Category Tier 1.
Create some Issue Category Tier 3 objects. These will be the third level of the categorization, so these are typically the most specific.
Just like with the Issue Category Tier 2, in this Object Type I added only one custom attribute, called Tier 2. This attribute stores a reference to an Issue Category Tier 2.
Now that the Insight Object Types and Objects have been created, it’s time to create some custom Jira fields to use on Jira screens where an issue categorization is needed.
First, create a Jira custom field of type “Insight Object/s” which limits the values to only those for the specific Issue Categorization Type needed. In the example here, I’ve named my Jira field Category Tier 1 and limited it to show only those Issue Category Tier 1 values for my ITIL Service Desk Issue Categorization (CategoryTypeID = ITIL – see Step 4).
Now create a Jira custom field of type “Insight Referenced Object (single)” which limits the values to only those valid for the selected Tier 1 value. In the example here, I’ve named my Jira field Category Tier 2 and limited it to show only those Issue Category Tier 2 values related to the Issue Category Tier 1 value already selected in the Category Tier 1 field.
Finally create one more Jira custom field of type “Insight Referenced Object (single)” which limits the values to only those valid for the selected Tier 2 value. In the example here, I’ve named my Jira field Category Tier 3 and limited it to show only those Issue Category Tier 3 values related to the Issue Category Tier 2 value already selected in the Category Tier 2 field.
The last step is to add all three of the new fields to a Jira screen and test them out. Here I select from the Category Tier 1 field the Hardware value.
Once the Category Tier 1 is selected, the Category Tier 2 values are limited to only those related to that tier 1, Hardware in this case.
Once the Category Tier 1 and 2 are selected, the Category Tier 3 values are limited to only those related to that tier 1 and tier 2, Hardware -> Desktop in this case.
We hope this was useful!
The instructions and screenshots above are based on Riada’s Insight Asset Management for Jira v5.5