We are integrating with both the Jira Search APIs and the OAuth 2.0 dynamic webhook registration flow. Recently, we began receiving the following error from the /search/jql endpoints: Unbounded JQL queries are not allowed here. Please add a search restriction to your query.
To comply with this requirement, we introduced a harmless global restriction using the JQL: project is not EMPTY
This works correctly across Jira Cloud, Jira Data Center, and all Search API endpoints.
However, after switching to OAuth 2.0 dynamic webhooks, webhook registration now fails with:
{
"webhookRegistrationResult": [
{
"errors": [
"Operator is not is unsupported"
]
}
]
}
It appears that the dynamic webhook JQL parser does not support the is not operator, even though it is valid in the standard JQL engine.
This puts us in a difficult position because:
Search APIs require a bounded query
Dynamic webhooks reject project is not EMPTY
Other fields such as created >= "1900-01-01" are also rejected with Clause created is unsupported in dynamic webhook JQL
We need a universal dummy restriction that works in:
Jira Cloud
Jira Data Center
OAuth 1.0
OAuth 2.0 dynamic webhooks
All Search APIs
Could you please provide:
A recommended dummy/neutral JQL clause that works with:
Search APIs (Cloud/DC)
OAuth2 dynamic webhooks
“All projects” selection scenario
Or, if no such clause currently exists, a workaround or best-practice guidance for supporting both bounded Search API queries and dynamic webhook registration.
We need an approach that is supported and stable across both Jira Cloud and Data Center.
That is a very obscure combination of factors to produce that scenario.
we introduced a harmless global restriction using the JQL: project is not EMPTY
Well, that’s not a restriction, that is an un-restriction, because, since the Project field can never be empty, you’re effectively saying “match EVERY project”. Although it’s a syntactically possible JQL expression, it’s logically meaningless.
What is the rest of the JQL expression that accompanies that? What are the specific characteristics of the Issues that you are looking for, apart from them being in every project?
However, after switching to OAuth 2.0 dynamic webhooks, webhook registration now fails with “Operator is not is unsupported”
Do both the Jira Cloud and Jira Data Center platforms return that error for that JQL expression, or only Jira Cloud?
The IS and IS NOT operators are not supported by the JQL for dynamic webhooks in Jira Cloud, as stated in the Register dynamic webhooks endpoint documentation, so the error message is the expected behaviour for the Cloud platform.
A recommended dummy/neutral JQL clause… or, if no such clause currently exists, a workaround or best-practice guidance for supporting both bounded Search API queries
That is a contradiction. A webhook with “dummy/neutral” JQL in it is, by definition, unbounded. The webhook’s JQL has to be specific, not non-specific.
Why not just create webhooks that have specific (ie bounded) JQL queries from the outset, and you won’t have the problem??
Hello @sunnyape , Well, that’s not a restriction, that is an un-restriction, because, since the Project field can never be empty, you’re effectively saying “match EVERY project”. Although it’s a syntactically possible JQL expression, it’s logically meaningless.
We had to introduce this because of the bounded query requirement with new search endpoints
as we don’t have any filter criteria. We want to get all issues from all projects on the server.
Do both the Jira Cloud and Jira Data Center platforms return that error for that JQL expression, or only Jira Cloud?
I haven’t checked it on Jira Data Center platforms as we are using admin webhooks in there, and this error comes up with only dynamic webhooks.
The ISandIS NOToperators arenot supportedby the JQL for dynamic webhooks in Jira Cloud, as stated in theRegister dynamic webhooks endpoint documentation, so the error message is the expected behaviour for the Cloud platform.
I don’t see any such thing mentioned in the documentation. I can see only this
The supported elements are:
Operators: =, !=, IN, and NOT IN.
Why not just create webhooks that have specific (ie bounded) JQL queries from the outset, and you won’t have the problem??
To repeat again, I can’t create webhook with bounded jql queries as the requirement is to get all the data from all projects on the server.
It’s simple, deductive reasoning… if the documentation doesn’t say IS and IS NOTare supported, then it’s logical to assume that they are not supported.
I can’t create webhook with bounded jql queries as the requirement is to get all the data from all projects on the server.
Well, I hate to state the logical answer, but as much as you really want to, maybe you can’t create such a ‘global’ dynamic webhook.
I’m pretty sure that Atlassian wouldn’t want people creating such a potentially ‘monster’ dynamic webhook that can send events for every single issue in an entire Jira Cloud instance, that’s why they put in these restrictions in place.
You are going to have to experiment and try to find an equivalent ‘pseudo unbounded’ JQL statement that is accepted by the API’s JQL parser that uses the supported operators, such as issueKey != "" or project != "" or project NOT IN (“Fake1”, “Fake2”) etc. If none of those JQL statement are accepted , then you’ll have to use some deductive reasoning and consider that you’re possibly attempting to use dynamic webhooks in a way you’re not allowed to.
Personally, I think (well, ChatGPT did help me with this ‘thinking’ ) the only viable solution is to not do that… only create webhooks that are constrained (as I previously recommended) to a defined scope, say, of Projects. Enumerate all the Projects in the Jira instance, then create multiple dynamic webhooks, each one having a JQL expression covering a set scope, such as project IN (ABC, DEF, GHI, …) then as more Projects are added to the instance, create new webhooks to cover that range. That’s why they’re called DYNAMIC webhooks… you can rapidly create and delete them depending on changing circumstance.
Sorry, I have no further advice to give beyond this. Someone from the Atlassian team will have to chip in as to why dynamic webhooks aren’t allowed to be so unconstrained as you wish them to be.
) the only viable solution is to