🔍 JQL: Jira Query Language

JQL: Jira Query Language: JQL is like a library card catalogue: instead of walking the shelves you ask for "books published after 2019, by this author, on this subject" and the l

JQL is like a library card catalogue: instead of walking the shelves you ask for "books published after 2019, by this author, on this subject" and the library brings back only those. A board shows you the shelves; JQL gives you a list filtered by your question. The question worth pausing on: with the board already showing cards, why learn a query language at all? Because a board is a VIEW and only answers a question someone configured in advance. "High-priority bugs assigned to me and untouched for 30 days" is not sitting ready on any board. Compare: if you know SQL, JQL will feel familiar -- field, operator, value and ordering line up with the same logic. But there is a critical difference: JQL is not a database language and cannot JOIN. It filters fields on a single entity (the issue); it cannot directly read a field of another issue that this one links to. Not knowing that boundary is the number one source of frustration when learning JQL. For QA the difference shows up here: a tester who looks at the board each morning wondering what to do is not doing the same job as a tester who opens six saved filters and sees pending verifications, reopened records and forgotten items in a second.

🎬 How a JQL Query Filters Jira

The SHOP project holds 2,400 issues. Instead of scanning the board card by card every morning, Ayse writes one sentence: "open, high-priority bugs assigned to me". In this film you will watch what happens behind that sentence.

Step 1 -- The query is written: `project = SHOP AND issuetype = Bug AND status != Done AND assignee = currentUser() AND priority = High`. Each `AND` adds a FILTER layer, narrowing the set.

Step 2 -- Jira applies each condition against the fields of all 2,400 issues, in order: first `project`, then `issuetype`, then `status`, then `assignee`, finally `priority`. The set shrinks at each condition; no issue's CONTENT changes -- only VISIBILITY is filtered.

Step 3 -- 18 issues survive all five conditions. This is a moment that reminds you JQL does NOT perform a database JOIN: everything is a field on a SINGLE entity (the issue), no field of another issue is ever consulted.

Finale -- Adding `ORDER BY priority DESC, created ASC` puts the 18 issues into the ORDER Ayse will see them in: highest priority first, and among equal priorities the oldest created comes first. This list, never visible on any board, is now Ayse's morning routine.

1️⃣ F1. The Anatomy of JQL

Where Do You Write This?

On a real Jira account, click the "Filters" menu in the top navigation bar, then pick "Advanced issue search" from the list. The issue navigator screen that opens has a "Basic / JQL" toggle in its top-right corner -- clicking "JQL" opens a search box with autocomplete suggestions where you type the syntax you see on this page directly. This same screen is also where you turn a query into a "saved filter" and set up a subscription (see F4).

A JQL query has four parts: FIELD (project, status, assignee), OPERATOR (=, !=, IN, ~, WAS, CHANGED), VALUE and an optional ORDERING (ORDER BY). Conditions are chained with AND / OR. The example below shows three queries a QA engineer uses daily -- the keywords are the language's own syntax and stay English even on a Turkish page; only the explanations change. The table that follows shows JQL as familiar yet critically different for those who know SQL.

To see which Story a bug was born from, can you write a JQL query like `story.title ~ "coupon"` directly?

Yes, JQL does JOINs just like SQL

No -- JQL does not JOIN, it only filters a SINGLE issue's own fields