So I’ve been using the following endpoint to grab the users: /wiki/rest/api/search/user?cql=type=user&limit=5000
Yes, I know the limit is set to 1000 but I like to add cushion just in case the limit changes and I can grab more.
Anyway, the issue I am seeing is that even with a limit of 1000, the call only returns (100) users. Usually, there is a next link to indicate there are more users to grab but I read a post that confirmed that this is missing for this endpoint.
In other code I’ve written, I was able to a “total or size” variable that gave me the total returned results that I could use to iterate to collect them all or use for paging. But this also seems to be missing—meaning it only gives the total returned not the total for the dataset.
So it looks like I have to iterate in increments (100) until it returns an empty set–which can be an issue for customers that have 1000+ users but what can you do if that’s the way it works.
Before I implement such crude code, I thought I’d ask the community to make sure I’m not missing anything (I’ve done that a couple of times before ).
To be honest, I think what you are missing is the fact that Atlassian really doesn’t want you to fetch all users
What is the use case for doing this??
While I can appreciate that, they have made it possible to obtain this data via their APIs so I’m just using it. I can do away with it in my Jira/Confluence cloud apps and create a new app using the User Management cloud APIs.
But customers have asked if I can add it to the apps they’ve already purchased and again, it is available in the Jira/Confluence cloud APIs so just thought I’d use it.
This isn’t a huge deal, just wanted to make sure I wasn’t missing anything or if there were planned updates since there’s a strong cloud push by Atlassian.
My apps are for admins and they pull a lot of data into a central location thus, eliminating the need for them to click all over the place to get the info or in this case leave Jira/Confluence to go to the admin tool to get number of users.
To be honest, with the recent cloud push, you need to start thinking about scale. We already have customers with 5000K+ confluence users. Do you really want to pull in all that data? If the answer remains yes, I would strongly suggest moving this to a background script on your own server running once a day to update the total users and store it in a DB. You also have to take into account rate limiting and performance here.
And what is really missing is a user picker.
I hear you. I have a client that would like to move to Confluence cloud but can’t because they have 90k+ users. I believe Atlassian recently scaled itself to handle 20k users, so that client is on hold until Atlassian is able to handle that many users, which I am told they will continue scaling.
But this begs the question of how Atlassian plans to address this issue. I know they’ve recently updated the Admin tool but how will that tool address such a user load?
If customers have 30k users (or more with Atlassian future scaling) that have access, how will the products handle accessing all of those users for things like the native User Picker in Jira?
Since my apps are admin-based, it pulls users on-demand when the link for Users is clicked and is not running constantly. But the Atlassian products will have to address accessing those users constantly (all day, every day) so the hope is Atlassian develops a solution that can be used.
For now, I will run some tests to see if I can determine a point where performance starts to suffer and just not roll this out to production mode.
Thanks for the feedback, it has been a pleasure discussing this with you.