Wanting to check for others - it appears that using an access token obtained from an OAuth2 enabled service account with read:jira-work / write:jira-work - doesn’t actually work for any search JQL. It is able to look up field information and some other APIs though, which makes the results confusing.
Is this expected behavior that basic JQL searches would not work when authenticated with OAuth2? Note - using the exact same service account, with an explicitly created API Token in the service account console - works fine.
Both I and many other people have been using the new Service Accounts configured with OAuth 2.0 scopes, both Classic and Granular, for a many months now and have had not encountered any of the problems mentioned in the original poster’s question. The results returned from any of the JQL based endpoints, such as the Search for Issues using JQL endpoint, are exactly as expected for the scopes applied to the account, and the same is true for any other API endpoints and their scopes.
I suggest that you might be just doing something basically wrong, so double-check your method with your API test tool and have a work colleague peer review your code.
If nobody in your team can uncover the mistake in your code or method, then post a new question with a FULL description of the entire problem, as per the How to ask a good question thread. If a genuine problem with the functionality of the new Service Account’s use of OAuth 2.0 credentials is found, then a proper bug needs to be logged with the dev help desk; simply posting “me too” in someone else’s unanswered thread isn’t particularly informative or constructive.
Atlassian support indicated to me (JST-1186249) that they were able to reproduce the symptom that I’m seeing. There has not been any further update on the case though.
It’s certainly possible that it’s account specific issue. If you have any thoughts on above requests, I’m certainly interested.
Note that it’s clearly authenticating ok with the token (i.e. I can see difference in custom field lists with/without the obtained access token), it’s just SOME of the endpoints are not returning useful results.
Thanks for provided a more detailed description of the problem.
I tried, but wasn’t able to replicate what you are describing. Here is my validation of my authentication and request method using Postman.
I have a particular Service Account that has only the two Classic OAuth 2.0 scopes of read:jira-work and write:jira-work . I generate a new Bearer token for it using the same method as you’ve used:
then use that returned Bearer token with a request to the same endpoint as you’ve used, with fundamentally identical request as yours, all works as expected:
If then switch the request to Basic Auth and use a key+token for a ‘plain’ user who has the equivalent Project level permissions, then I get the exact same results returned by the JQL search.
If you have an open support request to try and resolve what is going on, then proceed down that path and report back here when the cause of the problem has been identified.
Will definitely update when I hear something. Thank you for testing/validating and confirming it SHOULD work.
Out of curiosity - is the target of your search team or company managed? (Team in my case for this specific JQL, but have a mix of company managed on the tenant.)
The project ‘BPT’ I’m searching against is a Company Managed Project.
Since you are querying against a Team Managed Project, do you get the same result if you omit declaring the issueType in the JQL? IE, just search on Project=Inventory
You might have made the classic mistake of confusing GLOBAL Issue types that are used by Company Managed Projects with LOCALLY scoped Issue types used by Team Managed Projects.
When you use JQL like issueType=Application, Jira resolves “Application” to a global Issue type, not the project-specific Issue type used inside your Team Managed Project. Because those IDs don’t match, no issues are returned.
For Team Managed Projects, it’s better to refer to the Issue type by its ID, not its name, if you want your JQL to work correctly.
No change unfortunately. With just a simple project=’X’ I get no results returned on the search. Will continue to wait and see what support comes back with.
I’d expect either way for the above restrictions to be equivalent between basic auth and oauth+access_token based invocations. The issueType search is working ok with basic auth invoked requests.
FYI - Just got an update from Atlassian Support on this - apparently, it is only affecting customers that have Atlassian Guard enabled - which we do as part of the .edu tenant/account.
They’re discussing internally whether to create a ‘Public’ bug on it.
Looks like they have corrected the bug - at least for my testing. If anyone else seeing similar, probably worth checking. I don’t have any link/relnote or anything to share, but if they give me one I’ll update this thread.
