Gap list UM SIG
red = Has not been discussed or further discussion is needed.
yellow = Scheduled for discussion.
blue = Has been discussed, pending next steps
All Open User Management Features
https://folio-org.atlassian.net/issues/?filter=17213
App | Functionality | JIRA | Status and next steps | Notes | Use cases | + 1 (Name/Institution) |
Users | More Granular User View Permissions |
| Discussed in SIG meeting 8/7/2024 To be revisited to better define requirements |
| Need to have more granular view/edit permissions for various parts of user records to enhance privacy. Not all staff should have permission to view user addresses and other sensitive personal information | +1 @Uschi Klute GBV |
Check Out | Display Users Custom Fields at Check out. | Feature stories complete. Revisit once development begins. |
| Collected Use Cases:
| +1 @Amelia Sutton, Five Colleges | |
Users | Implement OpenSearch in Users | Draft feature completed. Needs to be discussed in SIG meeting, then pass to developers for cost analysis |
| Need accurate result counts when searching. | +1 @Amelia Sutton, Five Colleges +1 @Uschi Klute GBV
| |
Users | Allow override of failed renewal due to expired user | To be discussed in a future meeting
Maybe this should be on the RA SIG gap list instead? |
| When a user record is inactive it is not possible to renew that user's open loans through override. Instead staff must either temporarily reactivate the user or manually adjust the due date on the loans. Workarounds discussed in SIG meeting on 2024-08-07 Meeting Notes |
| |
Users | Show links to Requests on user records for users with the "Requests: view" permission | Originally reported as a bug: https://folio-org.atlassian.net/browse/UIU-3190 Could be addressed by: https://folio-org.atlassian.net/browse/UIU-1343 | To be discussed in a future meeting | UIU-1343 was originally part of an old draft feature https://folio-org.atlassian.net/browse/UXPROD-2136 which might be worth picking up again in the future. | Users who should not be able to edit Requests still need to be able to link from a user record to that user's requests | @Jenny Bodenhamer (Oklahoma State University) +1 @Uschi Klute GBV |
Users | Make it more clear which fields are being searched in a User search | Discussed on Mar 5, 2025 in the UM SIG Discussed 2025-09-17 Meeting notes | This is an extremely simple feature. Need to decide how we want the information presented to a user. |
| +1 @Uschi Klute GBV | |
Users | Ability to create a user in a single shot | Discussed on Mar 5, 2025 in the UM SIG |
| It would simplify the process for creating staff user records via the APIs |
| |
Users | Ability to Protect Fields from Being Overwritten by User Import | Discussed on Mar 5, 2025 in the UM SIG Discussed 2025-09-17 Meeting notes |
| When an institution's external patron data is incorrect, but bulk user imports are taking place daily we need to protect a specified user from having their record updated through user import. | +1 @Uschi Klute GBV +1 @Erin Weller MSU (not a high priority) | |
Users | Users Version history / Change tracker | Discussed on Feb 19, 2025 in the UM SIG |
| Helpful for troubleshooting issues with user loading Leipzig team will be developing this |
| |
Users | Add support for bulk deletion of users | https://folio-org.atlassian.net/browse/FOLIO-2052 https://folio-org.atlassian.net/browse/MODUSERS-229https://folio-org.atlassian.net/browse/MODUSERS-122 | Discussed 2025-03-19 Meeting notes Discussed 2025-09-17 Meeting notes | There appear to be several tickets floating around trying to accomplish the same thing. We need to identify which ticket we want to prepare for implementation. MODUSERS-122 Covers the basics, but does not check for dependencies. Is a dependency check a need for this? This should be brought up in the lists/bulk edit working group as it might be better addressed there. | Currently deleting users must be done one at a time. This would simplify and speed up the process of deleting multiple users. It is possible to use the /users DELETE endpoint with CQL to delete a set of users, but there is no dependency check before records are deleted. | +1 @Uschi Klute GBV +1 @Erin Weller MSU This has been brought up by many institutions over the years. |
Users | Allow libraries to hide not needed fields from the user records | We talked about this in one of the meetings some time ago but I couldn't find a ticket for that. |
|
| For example, we never use fields like Middle Name, User Type, Date enrolled, Default Pickup Service Point, etc., and we don’t want them to be displayed, so staff would see less noise, more useful info and also have to scroll less. | Douglas College |