Permissions setup - which permissions to restrict from users

At U Chicago, we’ve gotten to the first step in permissions, which is assigning our testers all permissions. Now we need to look at the next step, where we find permissions to restrict. Our instance is working on the notion that we won’t have to restrict much in terms of the permissions in the modules the Library staff will use, but there will be things we’ll have to restrict from most of the staff. I hope to use this post to create a list over time of the permissions that ought to be restricted, and to whom.

As a start, I believe we can restrict the okapi permissions without harming our testers’ ability to test. They show in the clients that I’ve looked at as okapi.all. They have individual permissions like okapi.deployment.delete, okapi.deployment.post, okapi.env.delete, and okapi.env.get. I’m not certain what these individual permissions do yet, but it’s the first set of permissions that I can restrict and see if it has any effect on our testers.

If anybody else sees permissions that ought to be restricted, I would be very interested in seeing more of them here.

Just to move our discussion here. RA will need a number of user management based permission sets. Some examples:

• controlling who can CRUD home addresses
• controlling who can CRUD fines/fees
• German work rules will also put quite a burden on this area, since there are restrictions on how a users work product can be tracked, but many US based institutions want exactly that information.

There are also permissions related to permissions. A person who hires/manages student staff will need to be able to assign permissions to a user, but shouldn’t be able to alter existing permission sets.

Just first thoughts.

We’ve discovered, in the UM-SIG, that we’ll need to control who can CRUD usernames in the users module.

Some initial thoughts:

• Any permissions related to security functions, e.g., password resets or changes, will need restrictions
• Deletion of records will need restrictions, in users as well as more generally across apps, I would assume;

And I agree with Andrea that the ability to modify permission sets should be restricted, because an unwitting change to that could impact quite a wide range of users in a system, intentionally or unintentionally.

Here we’ve discussed permissions broadly and in terms of restrictions:

• restricting certain user groups to only be able to view ledgers/budgets/funds
• controlling who can manages and operates fines/fees (basically operations linked to finances as with the example above)
• ability for certain user groups to assign permissions (for example to students, unit heads for new employees, …)
  -restricting who has access to any resets or changes in terms of passwords or anything system related that has system-wide implications. (there should be an admin, perhaps even a systems user group)
  -ability to control through permissions assigned to user groups who can change configurations for apps. It would be nice to distinguish between those who can do all CRUD operations in a particular app vs those who just need R or RUC or RU for instance.

Like Chicago, people have all permissions in our test instance. I’ve shared this discussion with others in the 5C to get their views as well.

we should keep in mind what @cateboerema says in her presentation https://docs.google.com/presentation/d/1eFe2qkzmgBVETa5tAfQ9Gxxjj61wLgCLs9n5DGCrTqM/edit#slide=id.g4186b100c6_4_5 (slides 10-17):
most important seems to be this:

• Data element-based (e.g. view user address) - This is not supported in FOLIO and it is a possible future feature
• Data value-based (e.g. edit users where Patron group = Staff) - This is not supported in FOLIO

Perhaps we should talk about this again, in a separate meeting together with members of RA SIG.

Hi Uschi - RA isn’t pleased with this. We understand that it isn’t possible for the MVP, but both of these issues need to go into the backlog.

Andrea