Skip FOLIO Project Navigation

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