Hi,
I want to use REST API to get the filtered issues from the saved filter JQL (im using a servce account). The filter View is shared to a specific Jira Group. The service account is part of that Group. The Group has admin permission on the project. but i got not results… I use this base URL :https://api.atlassian.com/ex/jira/ What am I missing? Thanks in advance!
Hi! With service accounts this usually comes down to one of these: 1. Cloud ID in the URL. The base URL has to include your site's Cloud ID, for example https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/search/jql. To find it, open admin.atlassian.com and take the string after /s/ in the URL. Don't use the Organization ID, because that gives 404s or empty responses. 2. Use the new search endpoint and ask for fields. /rest/api/3/search is being removed. Use /rest/api/3/search/jql instead, e.g. ?jql=filter=12345&fields=summary,status,assignee. The new endpoint returns only issue IDs by default (fields defaults to id), so without fields the results can look empty. 3. Token scopes. For search/jql the token needs read:jira-work, or the granular set read:issue-details:jira, read:issue-meta:jira, read:field-configuration:jira, read:audit-log:jira and read:avatar:jira. Reading the filter itself (GET /rest/api/3/filter/{id}) with granular scopes also needs read:filter:jira and read:jql:jira, among others. You can't change scopes on an existing token, so if any are missing, create a new token. Send it as Authorization: Bearer <token>. 4. Filter sharing isn't issue access. Sharing the filter with the group only lets the service account see the filter. Jira returns an issue only if the account has Browse projects in that project's permission scheme (plus issue-level security, if you use it). A quick test: call GET /rest/api/3/filter/{id}. If that returns the filter, sharing is fine. Then run its JQL directly through search/jql. In Jira, go to Space settings > Permissions > Permission helper, then enter the service account's email and an issue key to see what's blocking it. 5. currentUser() in the filter. If the filter's JQL uses currentUser() (e.g. assignee = currentUser()), it resolves to the service account, so it will usually return nothing. Docs: https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/ and https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-filters/
Hi @Michel Marcoux , @Thanasis Nikolaou has covered this really well. The cloudId gateway URL, /rest/api/3/search/jql returning only id unless you pass fields, and filter sharing not granting issue access are the usual culprits. The one I'd check first is "admin permission on the project". Administer projects doesn't include Browse projects, so the filter is visible but its issues aren't. Run GET /rest/api/3/mypermissions?projectKey=KEY&permissions=BROWSE_PROJECTS with the service account's token. If it comes back false, add the group to Browse projects, then call search/jql?jql=filter=12345&fields=summary,status. Also worth knowing: the Permission helper is under Settings > System > Admin helper (docs). Let us know what mypermissions returns!
Hi! Thanks for all the info. I review all the points you mentionned, and everything seems in order but it still returns no results :( if the service account is added directly in the shared view of the filter, it works, if it's just shared with the group that is part of, it dosent work. Michel
Hello @Michel Marcoux
Since a direct share works and the group share doesn't, the permissions on the project are fine; the question is whether Jira counts the service account as a member of that group. Two calls to compare:
GET /rest/api/3/myself?expand=groups
read:group:jira
read:jira-user
GET /rest/api/3/filter/{id}/permission
If that groupId isn't in the first list, the membership isn't reaching Jira (for example, the account was added to a different group with a similar name, or to a group in another org). Atlassian's docs say group share permissions are only returned to members of that group, which matches what you see.
Until that's sorted, sharing the filter with the project also works for accounts with Browse projects on it, so you don't have to add each service account by hand.
Hey @Michel Marcoux, sorry it's still coming back empty. I tried it on a test site with centralized user management, and a filter shared only with a group did return issues for a service account in that group, whether I added it through the REST API or through Add to group in admin, so it isn't a general limit on service accounts and group shares and you're probably looking at the membership itself.
A group's member list in admin can leave service accounts out (AX-1731), so I'd look from the other side, under Directory > Service accounts > your account > Groups, to see whether a group by that name is there at all, keeping in mind that the tab only shows names. If your org is still on the original user management with more than one site, a group with the same name can belong to another site (JRACLOUD-96708), and then the groupId from the /myself?expand=groups call Cloverkite mentioned is what you'd want to compare with the groupId on the filter's share, though I haven't tested that setup myself. Let me know what your account's groups show
It looks like you're new here. Sign in or register to get started.
