Improve capability tables navigation for authorization roles UI
Description
Environment
Potential Workaround
Attachments
- 10 Oct 2024, 12:32 PM
- 30 Aug 2024, 06:59 PM
- 30 Aug 2024, 03:41 PM
Checklist
hideActivity
Yauhen Viazau October 10, 2024 at 12:42 PM
Tested on https://folio-etesting-snapshot-diku.ci.folio.org/, https://folio-etesting-snapshot-consortium.ci.folio.org/ - works as expected
Table heights for each of the capability and capability set table are now limited. Scrolling added to each table.
Now it is possible to keep table header visible when viewing each line of the table.
See examples:
Yauhen Viazau August 31, 2024 at 3:01 PM
The solution described by Zak will cover the needs of QA.
Zak Burke August 30, 2024 at 6:59 PM
After a convo with @John Coburn and a review of the https://folio-org.atlassian.net/browse/UISAUTHCOM-10 PR #19, it looks like we only tried out 1/2 the suggested implementation for very-long-lists:
pass
virtualize
pass
maxHeight={500}
(or the height of your choice) in order to make the rows scrollable under pinned headers
I think maxHeight
gives us what we want. The point of virtualize
is to reduce memory consumption for long lists, but it's mostly a holdover from early MCL implementations that used infinite scroll instead of paging. i.e. because it was technically possible that you might try to scroll through 10k patrons while only displaying 50 rows at a time, you needed virtualize
to only render the displayed rows instead of all 10k. True, we have many rows, but not so many that virtualization is necessary. I don't love hard-coding a pixel-height value like 500
, but it's not terrible. Note the vertical-scrollbar in this screenshot, showing that we are 1/2 down the list of capability sets.
Overview:
It would be useful to have the "view, edit, manage, etc." panes pinned at the top of the page when scrolling so that the user could always check which column is for which action.
Pinned information about type (data, settings, procedural) would also be helpful for the same reason
Pinned information about whether it is a capability or capability sets table would also be helpful for the same reason
Context: QAs need select/deselect checkboxes for multiple capabilities/sets when creating or updating an authorization role for a test user.
Looking (scrolling) for the right action (view, edit, etc.) and the right type takes too long due to the size of the tables. The same for checking whether the current table is for capabilities or capability sets.
See example:
Acceptance criteria:
Action headers and table name (type) should be always visible when viewing capability (or capability set) tables.
“Capabilities“ (or “Capability sets“) accordion header should be always visible when viewing capability (or capability set) tables.