2cd38258bd6a did you figure out solution?

8.13.* is clearly impacted please add it in impacted versions.

As a result, a backport of this bugfix to 8.13 LTS is needed please.

Hello, we're also hit by this bug and are deploying only LTS. Please backport this fix to 8.13.x or release a newer LTS version if backporting is not possible. Thx

Will this fix be back ported to the LTS 8.13.x ?

Hello there!,

I am using Jira version 8.16.1 and I have this bug in my system. Do you know if this is fixed in newer version of JIRA?

Thanks and regards,

Alberto G. 

I created a support ticket

https://getsupport.atlassian.com/servicedesk/customer/portal/20/GHS-224926

Enabling Jira SQL logging will show almost 2000+ sql select queries looping all active users(we have 2000+ users) when we click the assignee dropdown list.

Each query will be logged to 3 lines as this pattern (here we take 12ms. So 2000 * 12ms = 24seconds to show the dropdown list with only top 50 users)

2021-07-22 12:41:04,089+0800 http-nio-8080-exec-21371 MyUsername 761x67650714x1 1fzlqw /rest/api/latest/user/assignable/search 0ms Connection taken. borrowed : 1
2021-07-22 12:41:04,095+0800 http-nio-8080-exec-21371 MyUsername 761x67650714x1 1fzlqw /rest/api/latest/user/assignable/search 3ms "SELECT user_name FROM cwd_user WHERE (lower_user_name = 'someone' ) AND (directory_id = '10200' ) ORDER BY lower_user_name"
2021-07-22 12:41:04,101+0800 http-nio-8080-exec-21371 MyUsername 761x67650714x1 1fzlqw /rest/api/latest/user/assignable/search 12ms Connection returned. borrowed : 0

I think sql queries looping all active users by WHERE is unnecessory and of low efficiency.

https://getsupport.atlassian.com/browse/PSSRV-13998
Customer gets a timeout message when clicking on the Assignee field dropdown button. Access Log requests show that it reaches 70-80s at times

tomcat-access-logs % grep -i "assignable" * | awk -F " " '{print $3 " "$7 " " $9 " " $11 " " $28}' | sort | uniq
- /favicon.ico 200 3
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username= 400 146
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818566470 200 88015
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818566471 200 81758 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818566472 200 71289
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818566472 200 73724
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818566472 200 79680 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942487 200 77602 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942488 200 83283 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942489 200 84833 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942490 200 77899 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942500 200 73615 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=a&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942491 200 16688 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=a&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942499 200 20523 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=ar&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942492 200 1169 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=ar&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942498 200 1494 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=ari&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942493 200 89 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=ari&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942497 200 126 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=aria&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942494 200 59 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=aria&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942496 200 89 "srstqr"
sourcesense.admin /rest/api/latest/user/assignable/multiProjectSearch?username=arian&projectKeys=EBBS&maxResults=50&startAt=0&_=1622818942495 200 63 "srstqr"

Hello,

I am part of a big organization too and we have around 160 000 users (only around 13 000 active ones). We just recently upgraded from Jira 6.4.12 to 8.13.2, and we encounter the same issue with the dropdown assignee list taking around 35 seconds to appear (not typing, just clicking on the arrow). I did not manage to reproduce the 50 users scenario yet but I will test it later, thanks for the info!

Anyway there is one particular point that I wanted to highlight here : In Jira 6.4.12 version, for the exact same amount of users, the dropdown assignee list was displayed instantaneously, literally, less than 0.2 seconds.

I checked and it looks to be the same API call that is done both in Jira 6 and Jira 7/8, so it looks like there was a bad update done on this particular API method, which is this one :

JIRA_URL/rest/api/latest/user/assignable/multiProjectSearch?username=&projectKeys={projectkey}&maxResults=50&startAt=0&_={sometoken}

Please fix this issue, this is very frustrating to loose performances on such a visible functionnality while upgrading JIRA. Eventually consider to re-use the previous Jira 6 version of this function or make a dark feature capable of bringing back the old Assignable research performances as if there is any added functionnality linked to this bug I don't see it.. But we should have the option to disable it if the performance impact is too big for us.

Hello,

Would it be possible to fix this bug in the next Jira Software version? 

The suggested workaround is not really helping in our case, as most of our support team are a lot less than 50 users so we cannot grant the "assignable" user permission to more than 50 users.

Thank you.

@Marcus Silveira thank you for updating the ticket with new information.

The description now looks more accurate because it accounts for the fact that the API request fetches a maximum of 50 users so when the maximum is not reached, it keeps looking.

But, even for smaller ammount of users, if there are thousands of users which is expected on big enterprises, if the last on the list (example: 10th, 20th or something else) for example is named with a later letter in the alphabet (example S or V, etc) then it will as equally be slow. This only shows that the way the product find people assignable to issues is not correctly developed targetting performance. It's pretty clear that the code is actually checking user by user and confirming if the user is part of a role because if the code would find project > assignable role > project roles and groups of people which have the permission > people that belong to those roles or groups, this should be a very quick thing to process.