You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
JQL (Jira query language) – is a powerful query language in Jira that helps to improve searching for necessarily issues and affects work efficiency.
You just write the values you need and get those issues that match them as a result. If you often use the same values for searching you can save it as a filter.
And if your queries are accurate and precise you can make filters that will be the basis for creating agile boards, gadgets, and reports.
The way you write a query can influence the speed and quality of your work.
We prepared some hints that help you to create queries «like a pro».
It’s a common case when a user needs to find issues that have one of selected values from a list in their field.
It can be done like this: product = cookie OR product = milk OR product = jam OR product = butter, but there is a big chance to make an error or to forget something because the query is too long.
The opposite operator IN makes the query quite short. You just need to separate the values with commas: product IN (cookie, milk, jam, butter).
It happens quite often when users create unnecessary “individual” filters.
For example, John wants to create a filter that shows issues assigned to him. So, he writes the query assignee = John and save it as “My issues” filter. At the same time, there is already assignee = Olga filter created by Olga.
It’s not a big deal but the more filters created the harder maintaining them.
It’s better to create just one filter like assignee = currentUser(). In this case, any user sees issues assigned to them.
Another example: a user wants to see a list of issues for the current version of a product. The query fixVersion = 1.3.0 will be out of date as soon as the work under version 1.3.0 is finished. But the query fixVersion in unreleasedVersions() always gives you the list of issues that has an unreleased version of a product.
This abstract way of writing a query without strong values is called JQL functions.
There are some examples JQL functions that can be used for:
There is a list of functions in Jira that can be used for searching for information which is true for the particular present moment.
The full list of functions you can find there:
One of the underrated methods of searching but still a good one is using parameter Category. Instead of making JQL queries as:
project = Alfa OR project = Beta OR project = Gamma
project in (Alfa, Beta, Gamma)
you can set a category for a project and use it for filtering.
For example, we have five projects. Three of them have the category “Development”, one of them – “Sales”, and the last one – “HR”. If we want to see issues for “Development” category, we write this JQL-query:
It’s more convenient when the number of projects is growing. There is no need in editing filters with every new project.
A few words about filter editing.
Jira administrators have to remember every filter. If an object is changed or deleted the filter using the object or object’s field option becomes useless or crashes.
And it’s difficult to find all of those damaged filters by yourself. The only thing you can do is waiting for users to complain about some non-working gadgets or some reports that show false data.
Another way of managing filters is using the app Subscriptions for Jira - Filter Manager. You can find all the filters that are damaged or contain a specific part of a JQL query with it.
Administrators can operate with any filters but users can manage the filters created by them.
Using JQL queries and functions definitely can make any work process easier, so we recommend Jira administrators to teach users at least the queries and functions we mentioned in this article.
The more correct queries the less useless work for everybody.