Improve capability tables navigation for authorization roles UI

Description

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.

Environment

None

Potential Workaround

None

Attachments

3
  • 10 Oct 2024, 12:32 PM
  • 30 Aug 2024, 06:59 PM
  • 30 Aug 2024, 03:41 PM

Checklist

hide

Activity

Show:

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 Check Mark

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 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: 

  1. pass virtualize

  2. 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.

Screenshot 2024-08-30 at 2.48.55 PM (2).png
Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Eureka

Fix versions

Release

Ramsons (R2 2024)

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created August 30, 2024 at 3:33 PM
Updated November 1, 2024 at 9:33 AM
Resolved October 10, 2024 at 12:44 PM
TestRail: Cases
TestRail: Runs

Flag notifications