nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Saved filter returns different results than direct JQL in /rest/api/3/search/jql

joris raffin

Hi everyone,

I'm investigating a strange behavior in Jira Cloud and I'd like to know if anyone has seen something similar.

What I'm observing

I have a saved filter with the following JQL:

key = SUPPORT-157895
AND NOT summary ~ "Ticket référence"

The filter is shared with all logged-in users.
When I retrieve the filter definition:

GET /rest/api/3/filter/18380

I get:

{
"id": "18380",
"jql": "key = SUPPORT-157895 AND NOT summary ~ \"Ticket référence\""
}

So the stored JQL is correct.

Direct JQL execution

Running the JQL directly through the API returns the expected issue:

GET /rest/api/3/search/jql?jql=key=SUPPORT-157895 AND NOT summary ~ "Ticket référence"

Result:

{
"issues": [
{
"id": "491823"
}
]
}

The issue is returned correctly.

Jira UI

Opening the saved filter in the Jira UI also returns the expected issue:

SUPPORT-157895

So the saved filter appears to work correctly in the UI.

Saved filter execution through filter ID

However, when I execute the saved filter through:

GET /rest/api/3/search/jql?jql=filter=18380

I get:

{
"issues": [],
"isLast": true
}

No issues are returned.

Additional testing

I created another simple filter:

project = SUPPORT

Executing it through:

filter = <new_filter_id>

works correctly through the API.

So the issue does not seem to affect all saved filters.

Original use case where the issue was discovered

The problem was initially discovered on a filter containing:

project = SUPPORT
AND summary !~ "Ticket référence"
AND created >= "2026-08-01"
AND created <= "2026-08-15"
ORDER BY created DESC

In the Jira UI:

974 issues

Through:

/rest/api/3/search/jql?jql=filter=<filter_id>

Only 3 issues were returned:

{
"issues": [
{
"id": "490138"
},
{
"id": "489422"
},
{
"id": "488590"
}
],
"isLast": true
}

This led me to isolate and simplify the problem.

What has been verified

Reproducible with multiple users
Reproducible with Jira administrators
Reproducible in Postman
Reproducible in Power BI
Filter definition returned by /rest/api/3/filter/{id} is correct
Direct JQL execution returns the expected results
Jira UI returns the expected results
Only filter=<id> through /rest/api/3/search/jql returns inconsistent results

Questions

Has anybody experienced discrepancies between:

Jira UI filter results
Direct JQL execution
filter=<ID> execution through /rest/api/3/search/jql ?
Is there any known issue related to:

summary ~
summary !~
saved filter resolution
Jira Cloud search indexing
Is there any way to force validation, refresh, or reindexing of the saved filter resolution used by /rest/api/3/search/jql?

Thanks for any insights.

Update
The issue appears to be specific to the evaluation of a saved filter through:

filter = <ID>
because the exact same JQL executed directly returns the expected issue, while the saved filter returns no results through the API despite returning results in the Jira UI.

Accepted answers

joris raffin

UPDATE :

Here is the official atlassion support answer :

I ran test on filter "XXX" and confirmed the issue is tied to the accented 'é' in the summary text, which prevents the JQL text search operator from matching and filtering the tickets properly.

All comments

Duc Thang TRAN

Salut @joris raffin

Pour cette partie

Saved filter execution through filter ID

However, when I execute the saved filter through:

GET /rest/api/3/search/jql?jql=filter=18380

I get:

{
"issues": [],
"isLast": true
}

Peux tu essayer avec ca ?
TonInstanceJira/rest/api/3/search?jql=filter%3D18380

joris raffin

J'ai exactement le même résultat sans aucun retour :

{

"issues": [],

"isLast": true

}

Sami Shaik

@joris raffin , your isolation is already good enough to point at the mechanism, and Duc's test narrowed it further: the old endpoint returning the same empty set means this is not /search/jql specific, it is how the stored filter's JQL is resolved when referenced by ID, which is a different code path from parsing JQL you send in the request.

Two facts you established matter most: the broken filters all contain a text operator on an accented string (summary ~ "Ticket référence", negated), and the filter that works has no text term at all. That narrows the hypotheses to two, and three tests separate them:

Unicode normalisation of the stored string. "é" can be stored as one code point or as "e" plus a combining accent. The UI and your direct call send whatever your keyboard produces; the stored filter carries whatever was in the browser when it was saved. If the index normalises one form and the filter resolver does not, filter=ID finds nothing while the same visible text typed fresh finds the issue. Test: create a brand-new filter, typing the JQL fresh, with identical text; if filter=<new id> works, it is the stored string, and re-saving the original filter after retyping the term should fix it.
Negated text term on a filter reference. NOT summary ~ x and summary !~ x are evaluated against the text index differently from equality clauses. Test: save a filter with summary ~ "Ticket référence" (no negation) and one with summary !~ "Ticket" (no accent). If only the accented ones fail, it is hypothesis 1; if only the negated ones fail, it is a resolver bug with negated text terms.
Ownership and sharing are not the cause. You ran it as admins and the filter is shared with all logged-in users, so filter=ID is not being resolved as a user who cannot see the project. Worth stating so Support does not send you there first.

Whichever test fails is your Support ticket, and it is a good one: the filter ID, the two JQL strings byte-for-byte (paste them from the API response, not the UI, so the encoding is visible), and the three results. If the retyped filter works, you also have a workaround for Power BI today: point it at the new filter and leave the old one for Support.

Rudy Holtkamp

Hi @joris raffin ,

Could it be that the credentials you use in the REST API call are from a different user then you use in the UI?

If that is the case then the REST API user does not have the same permission as the UI user.

Duc Thang TRAN

Dans ce cas, peux tu me dire

Quand tu exécutes rest/api/3/search?jql=filter%3D18380, est-ce avec ton compte ou un autre compte ?

Au vu du résultat retourné, j'ai l'impression que ce compte n'a pas accès au projet (Browse Projects), ou qu'une restriction de sécurité (Issue Security level ) est appliquée.

Cela pourrait expliquer aussi cette partie

In the Jira UI:

974 issues

Through:

/rest/api/3/search/jql?jql=filter=<filter_id>

Only 3 issues were returned:

joris raffin

Hi ! No I tried with different users and I have the same behaviour

joris raffin

Je l'exécute avec mon compte qui a un accès admin complet.
Ce qui est bizarre c'est que l'appel dans un navigateur fonctionne mais pas dans postman ou powerbi

joris raffin

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management