Repository navigation
Conversation
|
This pull request has conflicts ☹ |
95ed006 to
86e951c
Compare
|
As this testing been brought up at the sysadmin meeting? |
|
This pull request has conflicts ☹ |
|
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.
86e951c to
5906a8b
Compare
|
I generally like anything that improves performance 🚀 . The ACL tab is terribly slow on our production system...
However, users should be informed that they can only see the first 50 roles in the dropdown menu and that they need to enter some text to find other roles. One possibility could be to add a warning message to the ACL tab. |
|
Bug: When searching for a user, the search is now performed in the backend as part of the request. Before, searching was done in the frontend. The backend however only searches by So for example, if search for "leon" i would not find a user like Possible fix: opencast/opencast#8111 |
Adds PagedDropDown for the role dropdowns, which loads roles in pages of 50 as the list is scrolled or searched, and reverts the DropDown changes it makes unnecessary. This commit was AI generated
|
Use Run test server using develop.opencast.org as backend: Specify a different backend like stable.opencast.org: It may take a few seconds for the interface to spin up. |
|
This pull request is deployed at test.admin-interface.opencast.org/1660/2026-10-07_14-20-27/ . |
|
Put in the extra effort and attempted to implement an infinite scrolling list for the user and role dropdowns. So you can technically see all the users/roles if you want to. Scrolling very far will still run you into performance issues at some point, but the list also gets reset when closing the dropdown so those issues should not persist. Created a new component |
This branch has not been deployed
3 participants
Requires backend changes:
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.UPDATE: Is now able to do infinite scroll. 50 is now the default "page size", which is automatically increased by scrolling to the end. 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:
The limited number of roles may trick users into thinking that there are less roles then there actually are.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
UPDATE demo:
Bildschirmaufzeichnung vom 2026-10-07 16-29-18.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.