-
Suggestion
-
Resolution: Unresolved
-
None
-
1
-
In this issue we want to gather feedback from customers about current behaviour of mentions/assignees.
Description
In Jira 8.19.1 we change method for searching users in mentions and assignees to improve Jira performance and reliability. Due to this changes list of users is generated based on permission scheme level and in result the list can contains users that are not assignable/mentionable because of other permissions.
What changed and why
Changes
Since Jira 8.19.1 user lookup method for assignee and mentions became faster on large instances and keeps decent performance with scale. We achieve that by changing search method and now users are searched based on permission schemes. It allows us make huge performance improvement, but we also need to introduce a few limitations. The introduction of these changes was conscious and driven by the need to ensure the stability and the best possible performance of Jira, regardless of the size of the instance.
Limitations
Any other filtering-out options outside of permission schemes are no longer respected. In result list of users, returned during attempt to assign or mention someone, can contains users that shouldn't be there. But it only applies to the returned list, we still make validations during saving such mention or assignee.
For example when we try to mention user in issue who has no permission to see this one due to some issue security level, we can do that but such user won't get any notification nor see the issue.
Also when we try to assign user that has no permission to be assigned due to e.g. ProjectPermissionOverrides, the operation will fail.
Possible solutions
Here are couple of ways we consider, as improvement of UX in case the limitations prove to be significant inconvenience. Implemented in order to avoid situations when returned list will contains user which cannot be assignable/mentionable.
- Keep invalid users on the returned list, but marked them as not selectable.
- Stop showing such users. It would result in being some searches being empty, as long as username query will be long enough to point to a user which is not filtered out but such conditions.
- Make sure we will not make as many calls until the unfiltered list contains some max number users as we are back to the performance problems before our changes
Available workarounds
To achieve similar behaviour as before our changes, required permissions can be configured on permission schemes level as well.