Rest API - Search Issues by Description AND / OR Project AND / OR Key

[daniel.kirchhof]

Hello,

I'm trying to implement a search field where I can find issues by its description or project key, the issue key or a combination of them.

But I'm not really satisfied with the rest api at all...

So here are some example use cases:

1. "test": Get all issues with "test" in its description or comment or whatever
2. "PRO" Get all issues of project "PRO"
3. "PRO-1": Get all issues with "PRO-1" in its key ("PRO-1", "PRO-11", "PRO-12", "PRO-124" ...)
4. "PRO test": Combination of 1 and 2
5. "PRO-1 test": Combination of 1 and 3.

I started to use the issue picker api with more or less success.

1. `api/3/issue/picker?query=test` ✅
2. `api/3/issue/picker?query=PRO` ✅
3. `api/3/issue/picker?query=PRO-1` ✅
4. `api/3/issue/picker?query=PRO test` ❌
5. `api/3/issue/picker?query=PRO-1 test` ❌

Okay, no luck with 4. and 5. So I included `currentJQL`.

4. `api/3/issue/picker?query=test&currentJQL=Project=PRO` ✅
5. `api/3/issue/picker?query=test&currentJQL=Key~PRO-1` ❌

Well, 4 is working now, but 5. isn't, because I can't use `~` in JQL.

It is so weired that I can search by the key if I don't include anything else but can't if I'm searching for other words.

Another thing: If I want to include all issues (not only issues where I participated anyhow), I have to use an empty `currentJQL` parameter, so the "current search" will return something.

The `api/3/search` enpoint doesn't fit the requirements as well. Can't search with wildcards...

I'm thinking about to exclude some possibilities, so the user could only search

1. All issues by its descriptions
2. All issues by its keys (with wildcard, but without an additional query)
3. All issues by its descriptions and the EXACT project key

But the user experience will suffer, cause refinements of the search input wouldn't be straight forward and not really understandable.

 The last option would be: Query all issues of all projects, save them somewhere and use my own search engine.

By the way: Some ids or keys are integers others are strings?!

And why doesn't return the api a 401 if I'm not logged in / the api key is missing? It returns 200 with an empty result?!

---

Actually my question could be: How to solve the problem. But maybe its not a question anymore - its more a thread about frustration...

Cheers,

Daniel

[Bill Sheboy]

Hi @daniel.kirchhof -- Welcome to the Atlassian Community!

What problem are you trying to solve by implementing an issue search outside of Jira Cloud?  If you describe that problem it may provide context for the community to offer suggestions.  Thanks!

Next, JQL is not a SQL, and so has a narrower set of capabilities focused around answering questions about issues.  To learn what is supported with JQL, please look here: https://support.atlassian.com/jira-software-cloud/docs/use-advanced-search-with-jira-query-language-jql/

And if you do not find what you need there, please consider also posting a question in the Developer Community areas: https://community.developer.atlassian.com/

Kind regards,
Bill

[daniel.kirchhof]

Hello Bill,

thanks for your reply.  I didn't know that there is a dev community as well.

To answer your question: I'm developing an app where you can pick issues from jira to automatically create worklogs for it.

While I'm working on an issue, I roughly know the ticket number. For example, if the key is "PRO-344", I will type "PRO-3", look at the suggestions, don't find the issue so I will continue to "PRO-3 Testing".

Now I wouldn't find any tickets anymore.

But I decided to only allow a search pattern like "PRO Testing" and it will automatically set the `query` to "Testing" and the jql to `Project = PRO`.

EDIT: Oh, but if I know the exact key, I would like to search for "PRO-344" and it should return this issue as a single result. No good decision :(

[Bill Sheboy]

Thanks for that information.  For more wildcard-like searches, you may need an Atlassian Marketplace addon to add to JQL features.  I recall seeing some posts about other improvements to JQL and searches, but I do not know any specifics about those.

[daniel.kirchhof]

I see... I will rethink my approaches. Maybe I will find a simple solution which makes me happy.