In order to take our team’s workflow and reporting to the next level, I have made many changes to our JIRA project. Most of the changes were not difficult. Finding out what can be done in Jira, and how, was harder. This blog describes some of the tools, tricks, and limitations I discovered with the help of Google, my friends, and colleagues.

Jira is very configurable. Depending on the configuration some of the solutions below will not work for you or you may have better options.  I work at a subsidiary of a large corporation. We use on-premise Jira. Our Atlassian team is great to work with – to make support sane and scalable they created a set of standard workflows and enforce conformity where possible. No one wants to maintain 100+ workflows…

Some of the tips below are focused on users who do not have Jira administration permissions. Without administrative privileges, useful information can be a bit harder to get. E.g. the ids for custom fields.

Creating and Editing Issues

Our Jira create and edit forms have fields we do not use for our project. Your admin can hide most fields and create custom tabs to facilitate faster and more accurate ticket entry. Note that the fields in the default tab are always shown first. If you’re using a Jira board (Kanban or Scrum), you can set the variables shown in the detail view from the board > configure > Issue Detail View menu.

Fields that are placed on the default tab will not show in the Jira Issue View unless they have a value. This made it more difficult for my team members to update some custom fields which in turn caused this field to often not be updated. To force such a field to be shown your admin can create a default value like ‘- not set -’.

Custom Fields, List Values, and Project ID

To keep our Jira instance manageable our Atlassian team prefers to re-use existing custom fields over creating new custom fields for each use case. To help users better understand what these fields stand for, you can change the default values of text fields and change the field description on the create and edit screens to provide project-specific guidance.

When referring to custom fields in the API or the Issue Collector you cannot use the names but must use their ids (e.g. customfield_10442 for a field called ‘Request Notes’). To get the ID open the create form in its own window and inspect the field

You can get list values the same way. Alternatively. If you change a list value you can see the ID for the value in the issue history

Depending on the configuration you can get the project ID from calling the API from a logged-in browser https://YOUR JIRA DOMAIN/rest/api/latest/project/PROJECT_NAME

Issue Collector

The issue collector allows you to create forms for ticket entry with a limited number of fields. If you have use cases where only a few fields are required, you can focus the reporter and cut down on the noise. You can also set default values both for fields shown in the form and fields not shown in the form. [1] 

Limitations

Some fields like Labels and Linked Issues cannot be shown with the issue collector. [16]

In recent versions of Jira, the issue collector does not assign the reporter field to the current Jira/Confluence user. It tries to match the entered email to a Jira user. [15] If no information provided or no match was found the ticket is assigned to a default reporter user. See comments to [15] for workarounds.

If the identity of the reporter is important note that the user can enter any email address. You cannot reliably infer the reporter’s identity from the email address.

Link in your Wiki or Website to Create a Ticket

You can create a URL to create a ticket including presetting some values. You may get an alert message that the reporter or other fields are missing. This is a bit ugly but does not cause any problems. See below for workarounds.

https://jira.yourdomain.com/secure/CreateIssueDetails!init.jspa?pid=10475&issuetype=10101&labels=fromurl

The value of pid is the project id of your project. The value of the issue type is different for each Jira instance.

If your link is on a Confluence page and your Jira and Confluence share users you can avoid the reporter setting for logged in users with the script below inside the HTML macro:

<a href = "https://jira.yourdomain.com/secure/CreateIssueDetails!init.jspa?pid=10475&issuetype=10101&labels=fromurl&sreporter=" onclick="location.href=this.href + AJS.params.remoteUser; return false;"> Submit JIRA Request... </a>

Selecting tickets with JQL

JQL has some filtering capabilities out of the box some people are not aware of  [3]. including

WAS

status WAS IN ("Resolved",”Closed”) DURING "2020/01/01","2020/03/31")

CHANGED

Filter issues on the Assignee, Fix Version, Priority, Reporter, Resolution, or Status field value BEFORE, AFTER, DURING, or ON a date (range),  FROM old value TO new value. E.g.

status CHANGED FROM “in progress” TO “in review: AFTER “2020/01/01”

GitHub Status [8]

project = bamazon AND Development[pullrequests].open 

You can also display the development status in the issue detail screen by prefixing PRs with the JIRA key. This requires integration between your Jira and GitHub [4, 20].

ScriptRunner [20]

Adaptavist’s ScriptRunner plugin gives you some really useful additional selection options including status change dates. You can retrieve status change dates without ScriptRunner using custom fields and transition post-functions. See [2] for more details

Swimlanes

Categorize swimlanes using epics with labels

We use kanban and have separate swimlanes for high priority issues, service tickets, and projects. Some projects get their own swimlanes and the remaining projects share the “other projects” swimlane. We implemented this using epics and the project label. Our swimlanes look somewhat like this

By specifically defining the other projects swimlane we can assure we did not make a mistake. The moment the “Everything Else” swimlane appears with tickets, we know our logic is incorrect.

Hiding subtasks 

Some of our stories have a lot of subtasks which can be noisy. We used to always hide subtasks but found that sometimes people would close the parent forgetting one of the hidden tasks. We now show subtask and minimize the noise in two ways:

We use a “Hide Subtasks” quick filter (JQL: “issuetype not in (Sub-task)” )

We hide subtasks if they have the same status as the parent story. Our Kanban board sub-filter includes the JQL

NOT ( 
  issuetype = Sub-task AND (
  ( 
    (status in ("Work Queue") AND issueFunction in subtasksOf("status in (\"Work Queue\")")) OR 
    (status in ("Blocked") AND issueFunction in subtasksOf("status in (\"Blocked\")")) OR ...
  )
)

Receiving Search Results via Email

You can subscribe to saved filters [18], which can be very powerful. You can save the columns for saved filters allowing you to select the best information for your use case.

E.g. As the project manager of our team I have set up a daily email subscription with all blocked tickets that had a comment in the previous day. The filter includes the last comment* allowing me to review any new developments for these tickets without having to open the issue in Jira. 

* The last comment is not natively available in Jira to see [19] how to implement with ScriptRunner.

Acknowledgments

I have learned and borrowed from whoever can help me. Michael Cohn and Dave Liao have been amazing resources on my journey to a deeper understanding of Jira and Confluence.

References and links

[1] Advanced use of the Jira issue collector (Atlassian)
[2] How do I expose the date an issues moved to each status? (Atlassian)
[3] Advanced searching
[4] Connect Jira Cloud to GitHub (also has directions for Jira enterprise)
[5] Control Chart
[6] how to create an issue in jira via rest api? (stackoverflow)
[7] JIRA — Searching for tickets that have been commited to a development branch
[8] Advanced search reference – JQL developer status
[9] The Top 10 Jira Query Language (JQL) functions from ScriptRunnerira-query-language-functions/
[10] Working with search results
[11] Adding “last comment” in a Filter Results Dashboard
[12] JQL query for comments for particular user
[13] Script JQL Functions
[14] Advanced search reference – JQL operators
[15] JRASERVER-71186 – Revert functionality to match user session to Reporter field when providing feedback through Issue Collector
[16] JRASERVER-32070 – Ability to use Labels / Labels Field in the Issue Collector
[17] Search syntax for text fieldshttps://community.atlassian.com/t5/Jira-questions/How-to-remove-Epic-from-list-of-epics/qaq-p/418945
[18] Receiving Search Results via Email
[19] Adding “last comment” in a Filter Results Dashboard
[20] ScriptRunner
[21] Integrating with development tools

The opinions represented in this blog are my own and not that of my employer or the organizations that I work with.