-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
None
-
Affects Version/s: 11.3.4, 10.3.16, 10.3.19
-
Component/s: JQL Search
-
None
-
10.03
-
1
-
Severity 3 - Minor
Issue Summary
When using JQL key range comparisons (>, <, >=, <=) where the boundary issue key is not visible to the querying user due to Issue Security, the query returns total: 0 results with no error, even though there are issues in the numeric range that the user is allowed to see.
This breaks key‑range–based JQL patterns (e.g. pagination via key >= X AND key <= Y) because any range whose boundary lands on a security‑hidden issue will silently return an empty result set, causing undetected data loss in automation and integrations.
The behavior differs by why the key is not visible:
- Deleted/non‑existent issue: JQL can return a 400 error (“issue does not exist”) for certain operators.
- Security‑hidden issue: JQL returns HTTP 200 with total: 0, even when there are visible issues in the numeric range.
From a user’s perspective, the expectation is that key comparisons operate purely on the numeric part of the key (sequence number), and only filter out issues they are not permitted to see — not that the entire comparison becomes unsatisfiable when the boundary key is hidden.
Steps to Reproduce
Assume a project PROJECTKEY with the following conditions:
- PROJECTKEY-3168, PROJECTKEY-3170, PROJECTKEY-3171 }}and {{PROJECTKEY-3172 exist and are visible to User A.
- PROJECTKEY-3169 exists but is hidden from User A by Issue Security (i.e. User A has no permission to see it).
- Run a JQL range using the security‑hidden key as lower bound:
project = PROJECTKEY AND key >= PROJECTKEY-3169 AND key <= PROJECTKEY-3172 → {{total: 0}} *← BUG: expected issues 3.*
Expected Results
The comparison should not return 0 records silently. It should either give an error like it gives in case of non-existing keys or it should return the issues that are not hidden due to the security level.
Actual Results
The JQL returns 0 results silently without causing automations and integrations to behave incorrectly.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available