Hello,
We are trying to use the API to query the /user endpoint like so /rest/api/2/user?username=admin2
This is in our automated test suite and has been working successfully for several years. As of an hour ago (3:35pm PT) today we noticed that this no longer works. It is failing with the error message "The 'accountId' query parameter needs to be provided"
We have not made any changes to how we are using JIRA in the past year, so it seems like a bug or breaking change on Jira's end. Is this a bug that will be resolved soon, or do we need to change our code accordingly? It is affecting our users so would appreciate a quick resolution.
I found a similar issue here which suggests that there has historically been bugs related to this https://community.atlassian.com/t5/Jira-questions/Error-in-the-JQL-Query-Expecting-a-field-name-but-got-You-must/qaq-p/1157925
Thanks,
Jordan
Use the "myself" API if you need the current authenticated user.
/rest/api/2/myself
We had to switch after running into the same issue as well.
I had been using the 'username' param to get a list of all users just a few days ago. I have had to switch to using the 'query' param : https://<MyDomain>.net/rest/api/latest/user/search?query=%20&startAt=0&maxResults=100&includeInactive=true
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks. Yeah we used a similar work-around, though incredibly it seems the rollout was contradictory -- for some user search queries we are now seeing "The username query parameter was not provided" meaning that username is required for some of our client connections and banned for others...
/rest/api/2/user/search?query=displayName%3Da%25&startAt=0&includeInactive=true&maxResults=1000
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah figured it out. Some of our customers are using Jira Server and not Jira Cloud and thus are on previous versions that have the old behavior. I've handled the condition by querying serverInfo to see if the build date is before the 2020-04-15 which seems to be the one that introduced the breaking change.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I did some digging and I suspect this is related to https://confluence.atlassian.com/jirasoftwarecloud/gdpr-changes-to-usernames-in-jira-cloud-967319102.html (though that was deprecated quite some time ago).
Fine, we'll migrate to using accountId, however we don't seem to have a way of getting the accountId of the authenticated user (set up using Application Link) via the API. We have the username but no longer have a way of tying it to their accountId. How can I get the accountId/userKey of the admin user who set up the application link?
Alternatively, the reason we want this in the first place is so that we can get the timezone of the JIRA instance (via https://developer.atlassian.com/cloud/jira/platform/rest/v2/#api-rest-api-2-mypreferences-get). Is there another way to get the instance timezone? I tried using https://developer.atlassian.com/cloud/jira/platform/rest/v2/#api-rest-api-2-serverInfo-get but that only gives the serverTime with an offset (which cannot be reliably converted into a timezone because there are multiple timezones per offset).
We are a 3rd party tool, so cannot inspect or change any of the end user's Jira settings and would rather not ask for this information.
Thanks for the assistance,
Jordan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.