2023-04-19 Meeting notes

Dennis discussed how work on Enhanced Consortia Support will impact the Users Management module. See UXPROD-4049 for a list of issues that are being worked on. See also Consortia SIG

Generally, Dennis is working on ways for there to be interaction between separate databases (or 'tenants'). There will be one special tenant which has extra modules, esp. 'mod-consortia'. This special tenant will coordinate the 'inter-tenant' functionality. The login will continue to look the same (a single point of entry). Users will have a primary affiliation to a database (or 'tenant') which will become their active affiliation when they first login. Users with more than one affiliation will be able to change their affiliation (without having to logout) – analogous to the way Service Points work now where users can have a default SP but can have other SPs.

Permissions will be different depending on which is the active affiliation. A user with the active affiliation of 'Patty' may only see certain orders that are local to that database. If the user changed affiliation to database 'Laurence', then they would see only orders local to the 'Laurence' database. There is also the possibility that certain records may be made viewable / searchable across multiple databases although only editable in their 'home' database. Permissions will need to be assigned for each individual database a user has an affiliation with. The different databases will necessarily have their own individual permissions and permission sets available, as some databases may lack modules present in others. Uschi commented that it would be very helpful if a central administrator could handle permissions for a small library without the need for logging out/in.

The extra layer of complexity regarding permissions will make it more important to have a more efficient method of assigning permissions –  such as the UXPROD-3159, feature to allow assigning a group of users (such as student staff) to a permission set all at once.

Dennis asked if the person who creates permission sets is the same person who assigns permission sets. This is the case in some institutions, but not in others. Many libraries enable student supervisors to assign permissions to their student staff, as student staff can change frequently. At Duke, this is still under discussion, but they are leaning to having different people in different departments (Acquisitions, Metadata, RA, etc.) be able to create and assign permission sets, as well as allowing student supervisors to be able to assign permission sets.  Six SIG members said that they use one person to create sets and assign them to staff.  An action item for Maura: create a poll in the user-management Slack channel to see what other institutions do regarding creating/assigning permission sets.

Dennis wanted to know if there was a reason why you wouldn't want most users to be able to see another user's permissions. Several people regarded users being able to see another user's personal data (e.g., home address) as more pressing, and that seeing another user's permissions was more of an annoyance.  Brooks mentioned that being able to see permissions could be a security vulnerability – a user could see who has high permissions and trick that person into logging in and forgetting to log out, for example. 

Regarding use of permission sets vs individual permissions, four of the SIG members who responded said their institution used permission sets (for a 5th data point, I'm pretty sure 5C uses sets).

Regarding creating sets based on job role or other criteria, U of Chicago creates sets around function (which can then be nested into sets for different job roles). Functional permission sets are more flexible, if job roles are changed.

It was agreed that being able to compare the differences in permission sets would be a valuable troubleshooting tool. The ability to show all users who have a particular permission or permission set would also be very useful.