Dummy/Bounded JQL for Search API & Dynamic Webhooks

[AnubhavAgrawal]

Hello Team,

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:

1. A recommended dummy/neutral JQL clause that works with:

   • Search APIs (Cloud/DC)

   • OAuth2 dynamic webhooks

   • “All projects” selection scenario

2. 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.

Thank you for your assistance.

[anon96974232]

Hello @AnubhavAgrawal

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??

[AnubhavAgrawal]

Hello @anon96974232 ,
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.

[anon96974232]

@AnubhavAgrawal

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

Huh?

It’s simple, deductive reasoning… if the documentation doesn’t say IS and IS NOT are 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.

Good luck!