Working with invisible permissions

Owned by (OLD ACCOUNT) Erin Nettifee
Last updated: Dec 09, 2021

What are invisible permissions?

FOLIO permissions have a concept being either "visible" or "invisible."

Whether a permission is visible or invisible is defined by the developer who creates the permission.

Visible permissions are usually what a FOLIO user thinks of when they think of permissions. Visible permissions are generally (though not always):

  • Defined in a front-end UI module;
  • Groups of very granular (sometimes visible, sometimes invisible) permissions that are clumped together into one permission with one name;
  • Defined with a friendly name that displays (via translation) in the FOLIO UI. They have names like "Settings (Users): Can create, edit and remove patron groups" or "Finance: View Ledger"

Invisible permissions are generally (though not always):

  • Defined in a back-end module, not as part of a user-interface module;
  • Extremely granular - they may control one action in one function, for example, fetching a single record type in a single module;
  • Not named in a super readable way. They have names like "circulation-rules.storage.get" or"item.record.put".

Why would I want to know about invisible permissions?

Ideally, when you're working in the FOLIO UI, you never have to worry about invisible permissions, because the development process did the work of defining the visible permissions such that they include all the permissions you need to do your work.Ā 

However, because FOLIO is in active development, it does happen that you might need to assign an invisible permission to a user in order to troubleshoot a potential bug, or accomplish a workflow piece that can be handled no other way in FOLIO.

How can I see invisible permissions in the FOLIO UI?

The ability to see invisible permissions is determined user-by-user. The logged-in user must have access to Settings ā†’ Developer. In Settings ā†’ Developer ā†’ Configuration, check the box for 'List 'invisible' permissions in add-perm menus?', and Save your changes.

You should not leave this setting on permanently ā€“ there are over 4,000 permissions in FOLIO (visible and invisible together), and displaying invisible permissions will significantly slow down the add-perms user interface.


How should I configure FOLIO to use invisible permissions with user accounts, if I need them to be able to be assigned to multiple staff while waiting for a fix to be released?

It is possible for one account (say, a systems administrator with access to developer settings) to assign individual permissions to multiple FOLIO users, however, if other users in the system don't also have the ability to see invisible permissions, the systems administrator's changes could potentially be overwritten.

For example:

  • John Admin decides that Jeanne Dupont needs the invisible permission "circulation-rules.storage.get". John enables the invisible permission option in Settings ā†’ Developer, goes into the Users App, finds Jeanne's record and assigns the invisible permission to her.
  • A few days later, Max Mustermann realizes that Jane also needs the permission "Courses: Read All" to be able to see the Courses app. Max is a manager but not a systems administrator, so he can't see invisible permissions. Because of that, he doesn't realize that Jeanne's permissions were modified to add invisible permissions. He goes into Users, finds Jeanne's record, adds the permission "Courses: Read All" and saves her record. When he saves the record, FOLIO saves a complete new copy of Jeanne's permissions, which overwrites the changes that John Admin made.

There is a way to get around this, however, by using permission sets.Ā 

Example:

  • John Admin realizes that an error appeared in their current FOLIO version that won't be able to be patched until the next release, two months away. That error can be worked around if the users who are encountering problems are assigned the invisible permission "fancyapp.record.post."
  • John Admin goes into Settings ā†’ Developer ā†’ Configuration and enables 'List 'invisible' permissions in add-perm menus?" and saves his changes.
  • John Admin goes into Settings ā†’ Users ā†’ Permission Sets. He creates a permission set and names it "Workaround for Fancy App Error." In the permission set, he assigns the invisible permission 'fancyapp.record.post.'
  • Then, any user with permissionsĀ  - not just someone who can see invisible permissions - can assign the permission set "Workaround for Fancy App Error" to any user who needs it. Because it's a system created permission set, adding it to a user and then updating that user's record again in the futureĀ will not override the invisible permissions that should still be assigned to that person.