In case anyone else is having this problem. It seems once we upgraded from 8.20.6 to 8.20.10 (which includes this fix) the Micro Focus ALM Synchronizer plugin what synchronizes with Jira is broken for us. I have a call logged with Atlassian and ALM to look into this. Adding here for visibility in case others have the same issue and to see if they have any workaround. I've already tried limiting the assignable users on the project but that didn't work. 

Also, Activision Blizzard King (ABK) is affected by this ticket. Here is the support ticket: https://getsupport.atlassian.com/browse/PS-92671 This ticket is confusing because the Fix Version is 8.20.7 however that is what they just upgraded to when the problem starting happening to them. 

Thanks for the context Michal...

I think our route (looking toward Jira 9.0) will be to either
(a) re-architect the UI interaction to work more like Jira does, using the version of API that does targeted search direct to Jira (with some server side caching etc)
(b) ignore the "assignable" element of this, and just populate our server side cache using /rest/user/search (and error handle cases where we pick a user we can't use)
(c) populate our server side cache of users using /rest/user/search (or some other source of user account info e.g. ldap) and then post process that (as a background task) by making a lot of very specific (and hopefully very quick) calls to /rest/user/assignable API

So, lots of ways to skin the cat, but you've saved us trawling the API docs in a search for something that doesn't exist (yet)

At the beginning I'm sorry it turned out like we didn't care, I assure you this is not the case. Changes that impacted this endpoints, and now cause problems for you, was made to provide reliable way of lookups for assignable and mentionable users. Before these changes such operation could cause serious performance problems, for example:

• https://jira.atlassian.com/browse/JRASERVER-66816

• https://jira.atlassian.com/browse/JRASERVER-61939

• https://jira.atlassian.com/browse/JRASERVER-38532

• https://jira.atlassian.com/browse/JSWSERVER-20844

• https://jira.atlassian.com/browse/JRASERVER-70934

Our perspective with this endpoints was to improve user pickers and we changed this functionality with them in mind at the first place.

Can you provide a different way how we can provide the functionality to our users? We have a bunch of integrations that depend on this API

As f4cb74b5c51b mentioned, there is a rest endpoint rest/api/2/user/permission/search that allows you do exactly what user/assignable/search and user/assignable/multiProjectSearch does but with working pagination. The cons of this endpoint are
1) it require admin permission
2) it can cause some performance issues like user/assignable/search and user/assignable/multiProjectSearch does before our changes

This endpoint is deprecated because of performance issues and will be deleted any time in Jira 9.x, but no specific version has been given yet. However, it will remain in Jira 8.x.

Since Jira user pickers for assignable and mentionable users was improved, other possible solution may be delegating such integration directly to Jira. It also avoids redoing the searches Jira did to return all users.

We don't want that screen to directly interact from the browser to Jira, all our interaction with Jira needs to come from the server side of our application. We also don't want to be doing passthru requests on every key press as a user types in more of the user name (I did ask).

Referring to f4cb74b5c51b use case, server side integration can work as a proxy for requests even with some caching and other improvements if needed.

In Jira we also avoid making request on every key press by introduce debouncing mechanism on Jira frontend side since 8.19. User pickers with such mechanism have some short delay before sending requests to get more specific query to make. Maybe it would help in this case as well.

We will be grateful for any comments if this workarounds can meet your requirements and suggestions if you see any other potential solution we can provide.

In case current form of workaround and possible solutions were not acceptable for you, we create a feature request for Jira 9.0 to providing other way of obtaining all assignable and/or mentionable users. You can find it here: JRASERVER-73362

We also have a few integrations that depend on this API. We have use cases where we'd want to return more than 100 users. 

If the current version is 8.22.0 what is the date for 8.20.7?

Hiya Shari
8.20 is the Long Term Support version series, so Atlassian will back port fixes into that (as well as making them in the next full release)
https://confluence.atlassian.com/enterprise/atlassian-enterprise-releases-948227420.html

We were hoping they'd be able to get the API working again in 8.20.x as then we'd pick that up as part of our regular application of updates on the LTS version series... but guess we're going to be stuck with our workaround for now (and will need to find something different when we upgrade to the next LTS version and the deprecated API we're now using goes away).

MichaelB - The latest JS version is 8.22.0, so am confused by your comment yesterday regarding a fix in Jira 8.20.7.  Please advise thanks!

It is not a huge surprise to us that this was an unintended side effect of an attempt to improve stability of the existing API. These things happen.

What is surprising is that the response for paying customers who are impacted by the negative side effects of the changes is that we're just told "The documentation will be updated" i.e. tough, we don't care whether it used to support more users, it doesn't any more, we are effectively dropping this API and replacing it with a replacement that has the same name but does something different.

We have a couple of questions

1. Can Atlassian provide details of a working API that they will provide continued support for that will allow us to get a list of Jira users, using paging if required, which will covers more than 100 users?
Our particular use case is we want to know who we can assign new issues too... and as we noted above, we've found a temporary solution, but that API is also on the cards for getting shut down (at least it's been flagged up as being deprecated first though)

In the short term we have found a workaround by switching over to calling
rest/api/2/user/permission/search?projectKey=OURPROJECT&startAt=0&maxResults=1000&permissions=ASSIGNABLE_USER
but that (a) requires a user with project admin access, and (b) is a deprecated API

Is there another way to get a list of users who can have issues assigned?
Or do we need to head to /rest/user/search and just cross our fingers about whether they're actually able to be used as the assignee on a particular project?

2. Can you share with us details of Atlassian's policy with respect to deprecating and making backwards incompatible changes to the API?
We need to understand what the Enterprise Support we are paying for gets us if it doesn't stretch as far as maintaining the functionality of published APIs.
And we need to understand whether there is a way we can know which API methods have regression testing cover and can be relied on to work from one version to the next, and which API methods have the potential to break without warning as part of an upgrade.

Thanks
Antony Moss
Alfa Financial Software

Are you saying that the fix for not being able to lookup more than 100 assignable users is to formalize the limit of the first 100 assignable users by removing the {{ startAt }} parameter and changing the documentation so we are not confused? This is not a fix. You are saying there is no way to access more than 100 assignable users. Also any hope of using pagination is going away since you are removing the parameter required to implement pagination.

If Jira is to be officially limited to 100 users I expect the billing to also only charge for the first 100 users.   

Can you provide an different way how we can provide the functionality to our users? We have a bunch of integrations that depend on this API