2021-12-09 Resource Access Meeting Notes

Meetings in December and January (Holidays and Vacation days)
We cancel the dates between the 23rd Dec - 10th Jan (first meeting next year will be the 10th Jan)

Note taker: Andy Horbal

meeting_saved_chat.txt

meeting_saved_closed_caption.txt

Recording

60 Min

Permissions

Erin Nettifee

Refresh on Permissions

Permissions resources:

Introduction to FOLIO Permissions

Using Sample Role-Based Permission Sets on the Reference environments

Meeting Notes

Administrivia - Jana Freytag

The SIG discussed which meetings will take place as schedule in December and January (which are filled with holidays and vacation days). 12/20 will be our last meeting of 2021 (assuming that we have topics: if not, Jana will cancel this meeting as well) and 1/10 will be our first meeting of 2022.

Permissions - Erin Nettifee

Erin gave a presentation on permissions using the slides included with the agenda above.

A SIG member asked about the following hidden permission: https://folio-org.atlassian.net/browse/CIRC-1214. Without it, scheduled notices will not generate like they are supposed to.

Some fields show up in live FOLIO environments additional to the ones listed on slide three.

Information about how to assign a “hidden” permission can be found on the FOLIO wiki. A “hidden” permission is one which is “invisible” in the FOLIO UI. More information about visible vs. invisible permissions can be found on slide four.

Per Erin, the key takeaway is that permissions in FOLIO work because they can and are supposed to be nested within each other. There is no limit to how deeply they can be nested. This is meant to give FOLIO the best of both worlds: it gives us the ability to really finely control various aspects of the system, while not overwhelming the user interface or creating a scenario where you have to assign 500 permissions to someone for them to be able to do their job. This does, however, create terminology problems: a permissions set looks just like a permission in the COLIO code, for instance. The POs have had long discussion about how to make this more clear with no luck so far. Erin encouraged everyone not to get too hung up on the difference between a permission and a permissions set: just let it be confusing, look at the code, and learn what you can from what you’re seeing in front of you!

Role-based permission sets in Snapshot (like the “role-circ-observer” one shown on slide 10) were set up to mimic real-world roles, as opposed to diku_admin, which basically has access to everything. If you want to log in as a user with one of these sets, the username and password match the name of the set: e.g., the username and password for role-circ-observer are both circ-observer.

Question in chat: Has there been any thought to allowing admin users toggle "hidden" permissions on so that they can see them for troubleshooting purposes? Answer: This already can be done in SettingsàDeveloperàConfiguration.

Question: How can you differentiate between visible and invisible permissions? Answer: The most obvious way to distinguish between visible and invisible permissions is that the latter don’t generally have great names.

If you find that you need a hidden permission to make a workflow happen, please report that to the PO as a bug! They should be refining this as they go.

Question in chat: Wat does the "Act as though user has all permissions?" in config do? Erin did not know the answer, but she will find it and post it in the RA SIG Slack channel. Erin's answer in Slack: "essentially it sets a flag in Stripes (the User Interface code) that tells Stripes to act like the account that is logged in has all the UI permissions available. What that option doesn't do is give your account all the backend permissions like diku_admin does. In a production environment where you don't want anyone using diku_admin, that option would be useful for troubleshooting questions about people being able to see a particular app or function... but if you have access to the superuser account, you probably wouldn't use that feature very much."

How to find permissions could be its own presentation. Briefly, though, you can look in FOLIO after turning on developer tools, but Erin more often looks at the FOLIO code in Github.

Release notes should mention if new permission are added by an app. There’s also now a feature that allows you to deprecate a permission.

There is not a way to duplicate permission sets, but starting in Juniper FOLIO release, you can nest permission sets. For example, you could nest the permission set 'circ-student' in a permission set 'circ-manager'.

There are not any permissions that block a user from doing something in FOLIO. Either a user has the permission, and can do what the permission enables, or the user doesn't have the permission (in its most specific, granular form) assigned, and can't do what that permission allows. Therefore, there can't be "conflicting" permissions. FOLIO will automatically drop duplicate permissions (e.g. if a permission set and a permission within that set are both assigned to a user).