Introduction to FOLIO Permissions

Introduction

FOLIO offers an integrated permissions system that is configurable and very granular.

Each app provides its own permissions that are defined in the app's front-end and back-end modules.

FOLIO users can also build their own permission sets (groups of permissions) and assign those permission sets to FOLIO users. This can be very helpful in setting up individual system roles configured to individual library needs.

Naming Conventions

Permissions are named to indicate what a FOLIO user with the permission can do within the app.

Permissions are named in the following format:

[Appname]: [What the user can do]
Settings ([Appname]): [What the user can do]

Examples of permissions (current to Honeysuckle - Q32020):

That permission isn't named that way...

If a permission is not named following the standard naming convention, the most likely reason is that that permission is currently being worked on / developed by the developer team for that app. FOLIO product owners work with developers to request specific permissions be added to the code, and also to ensure the permissions are eventually named correctly.

If you have questions about a particular app permission, reaching out to the associated SIG or product owner is the right thing to do.

Permission example (screenshot)	What this permission does
	This permission applies to the Users app. The name describes what the user can do - if they have this permission, they can go to a user record in the Users app and view service points assigned to that user.
	This permission applies to the ERM Comparisons app (new to Honeysuckle. A user with this permission can create jobs to run in the app.

Key Terminology Definitions

CRUD: CRUD stands for "Create, Read, Update and Delete." You may see it used as a shortcut terminology in permissions discussions.
Permission Set: A permission set in FOLIO is one permission that includes one or more subpermissions. Permission sets can be created in the FOLIO system by a developer, and defined in the app's front-end or back-end code. They can also be created by FOLIO staffers who have access to Users settings in the Settings App.
- It's important to not get confused about the difference between permissions and permission sets.
- Permissions are defined by developers as they write code (informed by product owners, features, and user stories)
- But, permissions that developers write can and often do, themselves, have subpermissions.
- So a permission can have one or more subpermissions, and a permission set will have one or more subpermissions.
Visible Permission: A visible permission is one that you can see in the list of permissions in the UI. They can be assigned to patrons directly, or you can add them to a permission set through Settings → Users → Permission Sets.
Hidden or Invisible Permission: An invisible permission is hidden from the FOLIO user interface and is not usually assigned directly to a FOLIO user. It's commonly a permission that is part of a backend module, and is given to users as part of a permission set, not assigned directly to a patron.

Try not to worry about terminology

The difference between a permission and a permission set can be very confusing.

FOLIO permissions are designed to be building blocks, from very specific to more general, and are designed to interlock with each other.

In practice, most community members use permissions when it could actually be a permission set; for most library workflows, distinguishing between the two terms doesn't really matter, and they are used interchangeably.

How to find permission information in a FOLIO module

It can be helpful, if you are not sure what a permission is intended to do, to examine information about the permission in the associated code in the FOLIO github repository.

How to find this information can vary by module, but general guidelines are as follows:

For a UI module (named starting with UI-), look for a file called package.json in the repository.
- Example: the permissions for the ui-inventory module are at the top level of the module in a file called package.json
- Example: the permissions for the ui-finance module are at the top level of the module in a file called package.json
For a backend module (generally starting with MOD-), look for a file called moduledescriptor.json or ModuleDescriptor-template.json in the repository.
- Example: the permissions for the mod-circulation-storage module are in the descriptors folder in a file called ModuleDescriptor-template.json
- Example: the permissions for the mod-source-record-storage module are in the descriptors folder in a file called ModuleDescriptor-template.json

Permissions are usually defined towards the bottom of the descriptor file. Here are some examples of what a permission definition looks like.

Backend module, Simple permission with no subpermissions

{
	"permissionName": "customreports.item.put",
	"displayName": "custom reports item get",
	"description": "Edit an custom report"
}

Backend module, permission set

 {
	"permissionName": "eusage.all",
	"displayName": "eusage all",
	"description": "All permissions for the mod-erm-usage module. An admin should get all permission, e.g. to edit aggregators.",
	"subPermissions": [
		"usagedataproviders.collection.get",
		"usagedataproviders.item.get",
		"usagedataproviders.item.post",
		"usagedataproviders.item.put",
		"usagedataproviders.item.delete",
		"aggregatorsettings.collection.get",
		"aggregatorsettings.item.get",
		"aggregatorsettings.item.post",
		"aggregatorsettings.item.put",
		"aggregatorsettings.item.delete",
		"counterreports.collection.get",
		"counterreports.item.get",
		"counterreports.item.post",
		"counterreports.item.put",
		"counterreports.item.delete",
		"customreports.collection.get",
		"customreports.item.get",
		"customreports.item.post",
		"customreports.item.put",
		"customreports.item.delete",
		"erm-usage.files.item.get",
		"erm-usage.files.item.post",
		"erm-usage.files.item.delete"
	]
}

UI Module: Permission Set, Visible = True

 {
	"permissionName": "ui-inventory.settings.loantypes",
	"displayName": "Settings (Inventory): Create, edit, delete loan types",
	"subPermissions": [
		"inventory-storage.loan-types.collection.get",
		"inventory-storage.loan-types.item.delete",
		"inventory-storage.loan-types.item.get",
		"inventory-storage.loan-types.item.post",
		"inventory-storage.loan-types.item.put",
		"settings.inventory.enabled"
	],
	"visible": true
},

Things to note:

A permission or permission set must have the attribute "visible": true in order to
- Show up in the Users App for the assign permissions workflow;
- Show up in Settings → Users → Permission sets to be assigned to a user-created permission set for a particular FOLIO tenant.

Frequent Workflows

Resources for More Exploration

FOLIO permission model (platform-level discussion)

Releases Home - search for release notes from current and past FOLIO releases to review permissions information and changes over time

Current Permissions Documentation by App Area - this is a Google sheet, maintained by individual product owners as permissions are added to apps they are responsible for.