JQL “key" comparisons with issue keys hidden by Issue Security incorrectly return 0 results instead of evaluating numeric key ranges

XMLWordPrintable

    • 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).
      1. 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

              Assignee:
              Unassigned
              Reporter:
              Shiv Kumar
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: