Hi All, I can successfully send a series of Get Projects Paginated api calls to retrieve all Projects:
‘h ttps://your-domain.atlassian.net/rest/api/3/project/search?startAt=0&maxResult=50’
But, I wanted to include an optional JQL query to filter to a subset. The following is an example of where 1 project key is passed as a jql query.
‘h ttps://your-domain.atlassian.net/rest/api/3/project/search?startAt=0&maxResult=50&jql=key=ABC’
This does not appear to work as it still returns all Project results. What am I missing?
I have found that I can use Keys array to filter projects, but I would prefer using the JQL string:
‘h ttps://your-domain.atlassian.net/rest/api/3/project/search?startAt=0&maxResult=50&keys=ABC’
The keys array works to return one result.
My jql query appears correct because I can send a similar Issue search like:
‘h ttps://your-domain.atlassian.net/rest/api/3/search?startAt=0&maxResult=50&jql=project=ABC’
The jql is recognised so my paginated list only contains issues under the ABC project.
Hello @DarylLynch
Nothing. It’s perfectly valid request and it’s doing exactly what you asked. You’re just telling the Get projects paginated endpoint to find issues, when it can’t… it just returns projects.
Your JQL query for key = ABC is a request to find an issue, since the word ‘key’ is one of three aliases for ‘issueKey’. So that part of the request is ignored and all that remains is a request for a paginated list of all projects, starting at 0 to the first 50 found.
You seem to be confusing what can be searched for via JQL with request parameters that can act as request result filters. The parameter keys works with that endpoint to filter the request results IE: &keys=ABC. The word key used in a JQL query is not the same thing.
Thank you, I understand where I was getting confused by the concept of JQL versus Query in Project API calls. I will switch to using the Keys parameter array.
No problem. Just a note that it’s good etiquette on the forum to mark answers correct if you think they are correct.
To further expand on the topic, the Get projects paginated endpoint accepts another parameter ‘query’:
query. string. Filter the results using a literal string. Projects with a matching key or name are returned (case insensitive).
So, you can use that parameter as an input filter to find specific projects based on their key before those results are further filtered by the keys parameter, like this:
/rest/api/3/project/search?query=ABC
which would achieve the exact same result as you are trying to do and return just one project, the one with the key ‘ABC’, but probably more efficiently, as you asking the endpoint to find only one project, not all, to start with.
Whereas the request:
/rest/api/3/project/search?query=ABC&keys=DEF
does the job of finding the project with the key ‘ABC’ , but then the keys parameter specifically excludes it from the results by acting like an output filter.
There are a number of endpoints that support parameters that can duplicate each other’s results or can cancel each other out, depending on how you use them.
Thank you again. I now understand how the ‘?query=ABC’ works in the API call. The following did not quite work though ‘?query=ABC,DEF’. I will use the Keys array instead.
Hmmm. I’ve been doing some testing, and the query and keys parameters don’t work as I remember, with an array created using multiple values separated by commas. Multiple keys parameters need ampersands between each, and the query parameter seems to accept only a single value.
Rats!!!
I’ve altered the answer above, in case someone else reads it and tries it as I originally typed it.
So, what works to find a set of projects by their keys is to use an IN() operator in the JQL, then use multiple keys parameters to filter (or not filter) the results, like this:
/rest/api/3/project/search?jql=project IN (ABC,DEF,GHI)&keys=DEF&keys=GHI
The longhand version of that JQL would be:
/rest/api/3/project/search?jql=project = ABC OR project = DEF OR project = GHI&keys=DEF&keys=GHI
Whew! Got there in the end.