Group members are not found in the user picker assignee field or when trying to mention them

Summary

Normally, when the Assignable Users project permission is granted to a specific group, the members of this group should be found in the assignee field dropdown when they are searched, as illustrated in the screenshot below:

However, under some circumstances, group members might not be showing in the dropdown when searching for them in the assignee field (a "no matches" message will be displayed), as illustrated in the screenshot below:

Similarly, members of the groups that have Browse Projects project permission should be able to be mentioned in the comments or description of the issues from that project. However, when trying to mention them, the warning "Found no matching users for xxxxx" is shown:

This KB article describes a scenario where this issue might happen, when using Jira 8.19.1 and any higher version.

Environment

Jira Server / Data Center 8.19.1 and above

Diagnosis

• The Assignable Users permission (applicable for the assignee field) / Browse Projects permission (applicable for mentions) is granted to a group that the impacted user is a member of. Example:

  
  

• The permission helper confirms that the impacted user should be granted the Assignable Users permission (applicable for the assignee field) / Browse Projects permission (applicable for mentions) due to its group membership. Example:

  

• For the assignee field issue: despite no matches found, if we leave the user's username in the assignee field and click on the Create button from the Create Issue screen, the issue gets created and the assignee field is set to that user:

  

• When checking the Jira application logs, the following WARNING is thrown at the time the issue was replicated:

  1 2 2022-06-10 13:29:39,255+0300 http-nio-8080-exec-9 WARN XXXXXXX 809x316882x1 163rd3u XX.XXX.XXX.XXX /rest/api/latest/user/assignable/multiProjectSearch [c.a.jira.permission.DefaultIssueUserSearchManager] Requested top N=200 and is greater then max top allowed: 100. Enable trace logging to see stack trace. 2022-06-10 13:29:39,626+0300 http-nio-8080-exec-9 WARN XXXXXXX 809x316882x1 163rd3u XX.XXX.XXX.XXX /rest/api/latest/user/assignable/multiProjectSearch [c.a.j.crowd.embedded.QueryDslJiraCrowdDAO] JiraCrowdDAO#findTopUsersWithNameInGroups: the results of the search might be incomplete due to too many groups. Number of groups: 1436, batch size: 1000, number of batches: 2. Allowed number of batches: 1.Learn more: https://confluence.atlassian.com/x/QBrSQ

• The group that is granted the Assignable Users permission (applicable for the assignee field) / Browse Projects permission (applicable for mentions) is synced from an external Active Directory, and has a high number of groups nested understand it, with more groups nested under the nested groups.

Cause

This issue is happening because of the way the "mentionable and assignable user" search was optimized in Jira 8.19.1, as per the KB article Mentionable & assignable users - tips & tricks.

As explained at the bottom of the KB article, the search does the following while searching for assignable or mentionable users:

• get top level group (groups) from permission scheme configuration

• if there is at least one directory supporting nested groups search for all subgroups (currently stopping resolving groups when - - the nested level is > maxGroupNestedLevel - 20 by default); we are running an sql query for each nested level;

• we search for users in batched sets of groups (by default 1000)

• by default we will only process up to numberOfBatches (default 1 batch = 1000) of groups

If a group which is assigned to the Assignable Users permission (applicable for the assignee field) / Browse Projects permission (applicable for mentions) contains a huge number of groups nested underneath it at multiple levels (>1000 nested/sub-nested groups), the following will happen:

• since the "user search" can only scan for users through maximum 1000 groups, some users will be missed by the search

• using the log snippet above as an example:

  • the search found 1436 groups that it needs to iterate through to find all the assignable users. Since the max groups that are used by the search is 1000, there will be 436 groups ignored by the search

  • the users that belong to these extra 436 groups will not be found by the search

Solution

There are 2 possible solutions, the 1st solution being the most recommended one since the 2nd solution requires changing some Jira property setting which could have some impact on the overall user search performance.

Solution 1 (Most recommended)

Understand the hierarchy of the group that was added to the Assignable Users permission (applicable for the assignee field) / Browse Projects permission (applicable for mentions) , and try to tune the structure itself (for example, by limiting the number of all the sub-groups and sub-sub-groups and so on), so that there are less than 1000 groups nested underneath it.

Solution 2 (Less recommended)

This solution consists in increasing the number of groups which are used by the "mentionable and assignable user search" to a higher number (for example 2000).

Here are the steps to implement this solution:

1. Add the following JVM startup parameters by following the steps from the documentation Setting properties and options on startup:

   1 -Dcom.atlassian.jira.crowd.embedded.JiraCrowdDAO.groups.numberOfBatches=2

2. After you updated the JVM parameter on all the Jira nodes, re-start the Jira application (or re-start each Jira node 1 by 1 in case of Data Center)

3. After all the nodes have been re-started, verify that the impacted user is now searchable

Notes about solution 2:

⚠️ You need to make these changes on each Jira node, if you are using Data Center with a cluster of nodes

⚠️ The JVM parameter mentioned above means that the user search will use 2 batches of 1000 groups, so it will iterate over 2000 groups total. If you saw in the WARNING from the Jira logs that the number of groups is higher (for example, between 2k and 3k), you will need to set the JVM parameter to 3 instead of 2.