Improve ACL tab performance by lazy fetching - #1660
Open
Arnei wants to merge 1 commit into
Open
Conversation
10 tasks
Contributor
|
This pull request has conflicts ☹ |
Arnei
force-pushed
the
acl-role-picker-server-search
branch
from
September 4, 2026 07:15
95ed006 to
86e951c
Compare
Member
|
As this testing been brought up at the sysadmin meeting? |
Contributor
|
This pull request has conflicts ☹ |
Member
Author
|
So far it has not been, but I would like to bring it up there, yes. |
The Access Policy tab (and the corresponding wizards) fetched every role in the system (limit: -1) on open to populate each role dropdown client-side. On instances with many thousands of roles this was a multi-second, multi-megabyte request fired once per open. fetchRolesWithTarget now accepts query/limit/offset/hasUser, and AccessPolicyTable's role dropdowns search the backend as the user types instead. The parent components only fetch a single role up front, just to read the isSanitize flag that decides whether users and non-user roles are split into separate tables. DropDown gains a loadOptionsOnMount flag so a fetchOptions-based dropdown can skip its eager default-option fetch on mount (used here since AccessPolicyTable renders one dropdown per existing policy row, which would otherwise fire one identical request per row on tab open) and instead fetch its default option list lazily, the first time that particular instance is opened. This also fixes the virtualized MenuList silently rendering nothing instead of react-select's no-options/loading message when there are no options yet.
Arnei
force-pushed
the
acl-role-picker-server-search
branch
from
September 11, 2026 07:34
86e951c to
5906a8b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Includes #1655.
Requires backend changes: opencast/opencast#7958
The Access Policy tab (and the corresponding wizards) fetched every role in the system (limit: -1) on open to populate each role dropdown client-side. On instances with many thousands of roles this was a multi-second, multi-megabyte request fired once per open.
This PR implements a suggestion made by @ltekbas in #1442, more specifically the "typeahead input". Roles are not eagerly fetched anymore, but only when a role dropdown is clicked on or searched in. Furthermore, the fetch request (and thus the dropdown options) set a limit of 50. Figuring out which role are user roles (for Opencasts with role sanitization disabled) is now done in the backend, further reducing load (and is the thing that allows us to drop eager fetching in the first place).
Pros:
Cons:
I tested this on a local instance with 10.000 users, where it performed well. I am still somewhat concerned about the usability implications of this change, so ideally we get this tested by our heavy users.
Short demo:
Bildschirmaufzeichnung vom 2026-08-24 10-52-37.webm
How to test this
Requires an Opencast with the necessary backend changes, but that should be it.
AI Usage
Claude Sonnet was used for analyzing if a typeahead search dropdown was even possible in this case, and for making the necessary changes.