Permission Tree Display - Root Entries do not Respect Sort Order
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
3.11 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Evergreen 3.2.4ish
Using the "Permission Tree Display Entries" interface in Local Administration, it is possible to create a user-defined order for displaying permission groups in the Patron Registration/Edit screens.
This function works well for the most part. However, if groups are added as "Root Entries", i.e. they have no parent group, and then rearranged, the new order is not respected when viewing their display in Patron Edit/Registration. (The desired order does display correctly in the Permission Tree Display Entries interface, though).
For root entries, the displayed order seems to be based on the id order in permission.
For example, if I add three entries to the tree with id/position:
1 / 1
2 / 2
3 / 3
and then update the order to id/position:
2 / 1
3 / 2
1 / 3
Patron Edit/Registration will display them in id order 1, 2, 3.
I think the issue with id goes further, as well. The following may not be experienced by many, (or any), staff, but it's worth mentioning since it is seems very related.
Permission groups will only display under a parent group if the child group has a larger ID, (i.e. 10), than the parent group, (i.e. 5). If the ID is not larger, it can lead to a lot of issues with display and use.
For most users, this should not be a problem. Because child groups can only be added to a parent group once the parent group exists, the child group's ID is going to be larger than the parent group. I only ran into this issue because I created a tree at the consortium level that I wanted to use as a base for a handful of my libraries. We have a large number of groups, so it made more sense to try to duplicate the display in the database for the special org units and then make small changes in the client. This led to a LOT of issues and frustration that was finally solved by adjusting id and position so everything could live in harmony.
In an ideal world, the Permission Tree Display should disregard id order and base positioning on position and parent structure.
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
milestone: | 3.12.4 → 3.12.5 |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Confirming that this is still an issue in 3.7 - you can reorder non-root entries but not root entries. We get around this by adding Patron and Staff first then adding entries to those groups, but the interface is not very clear on how you should do that.