Repository navigation
Conversation
I'm rather confused as to how we got here. Subgroup searching needs to work. If this is a regression in the API then it does make sense to get rid of the search box until that is fixed. But the solution would be to send the issue to one of the core teams for resolution. So closing the issue as fixed is probably the wrong move. @edewit Are you sure that this is a server-side problem? |
|
Functionally we would prefer if the child group search keeps working. It's more convenient for the user to preselect the parent group, especially when there are many parent groups with many child groups. |
|
Yes @ssilvert it's a server side problem, it used to be that all the groups where fetched and then there was a client side filter to filter the child groups. But now it's changed to improve performance and the subgroups are paginated, but there is no support for a subgroup filter. You can still find the subgroups with the search functionality though |
Oh, I see that the search in the tree pane will work for this purpose. So the requirement is still fulfilled. I think this PR is fine to close the issue. |
fixes: keycloak#28818 Signed-off-by: Erik Jan de Wit <erikjan.dewit@gmail.com>
OK. I guess we can merge this PR but leave the issue open and transfer to the core team. |
|
Just to see if I understand the original problem correctly. In previous versions we were filtering sub-groups on the client side? |
|
@pedroigor that is correct, long lists that are not paginated by the server are paginated and filtered by the client |
Signed-off-by: Erik Jan de Wit <erikjan.dewit@gmail.com>
|
superseded by #29011 |
Signed-off-by: Erik Jan de Wit erikjan.dewit@gmail.com