2022-03-28 Resource Access Meeting Notes

Time	Item	Who	Description	Goals/Info/notes
2min	Administrivia	Jana Freytag	Jana Vaccation: 11 - 21 April Please let me know, if you could take over convening for: Mon: 11th Thur: 14th Mon: 18th	Note taker: Elizabeth Chenette meeting_saved_chat.txt meeting_saved_closed_caption.txt
30Min	Permissions Management Improvements for Morning Glory	Erin Nettifee patty.wanninger	UXPROD-3614 - Getting issue details... STATUS

Meeting Notes

Administrivia

Jana will be on vacation April 11, 14, 18, 21. April 21 will be a CDL subgroup meeting. Jana is seeking a substitute for her for those meetings to input the attendees and keep the meetings on track. Jana says she could set up the pages in advance if someone is willing to convene the meetings.

Erin Nettifee and Pattry Wanninger -- Permissions Management Improvements for Morning Glory

Discussion of https://folio-org.atlassian.net/browse/UXPROD-3614 and https://docs.google.com/presentation/d/1axIHIOH8j-k1Hi4xi8yyeCp09APLiGZ_gYJw_TYnBbc/edit?usp=sharing

In Kiwi, and prior to Kiwi, permission management controls were too broad. If you had the ability to assign permissions, you could assign any permission in the FOLIO system to that person, and that includes permissions on the system side that could allow people to stop and start FOLIO modules and install their own FOLIO modules.

With Lotus, the developers wanted to change the default permission behavior and create more granular permissions. They created 3 permissions, and these are invisible permissions:

users.assign.mutable (permission sets) -- can be changed after a module is started
users.assign.immutable (permissions) -- cannot be changed after a module is started
users.assign.okapi

Default permission management behavior was changed so that you could only assign permissions that you already own to other users.

The developers had assumed permissions management only happens with users who have diku_admin user permission. This caused problems during Bugfest.

Some changes were set up in Lotus to correct this. No permissions will be removed. They will stay as defined. There’s no disruption for Lotus. If you are upgrading to Lotus, you will be able to continue to operate the way you have been, if you have someone who has ui-users.editperms permission (“Users: Can Assign and unassign Permissions to Users”). Perms.users.assign.mutable and perms.users.assign.immutable will be added to ui-users.editperms

Question – will things stay immutable?

Answer -- Yes. If you are in the permissions management tool in FOLIO. Anything labeled as a permission is immutable. Cannot change unless you stop and restart, but you can add it to a permission set.

If labeled permission set, you can add a permission to it, and everyone with that permission set when they log out and back in would have that permission.

Questions that Erin proposes we consider in determining how this will work in Morning Glory:

Are there use cases for permissions management where FOLIO users should only be able to assign permissions that they already own to other users.
Are there use cases for permissions management where FOLIO users should only be able to assign locally created permission sets to other users?
Should a user be able to “Unassign all permissions” even if they include permissions that person doesn’t own?
Do we need to change any part of the UI with the new permissions restrictions to try to make this functionality clearer?

Question --What happens if assigning a permission set fails?

Possibly provide a friendly error in the event that somebody does something that they aren't allowed to do?

Possible Use Cases for Bullet 1

For example, you own a permission set “Cornell circulation,” and in Cornell circulation there are sub-permissions. In FOLIO, you own all the sub permissions and permissions, so you would be able to reassign Cornell circulation to someone else.

If you decided the “Cornell circulation” permission set also needs “courses Read all,” and your admin put that permission into Cornell circulation, then as long as you had Cornell circulation assigned to you, then you could continue assign Cornell circulation permission set to other users. Permission control is on the core of the thing.

Another example, Hiring a new staff person in Circulation who needs Inventory permission, normally considered to belong to another area. The circulation manager who assigns permissions to new employees can continue to assign the “circulation services” permission set to people in the department. But they may or may not be able to go in and assign “inventory create item” as its own individual permission to a new user. If the circulation services permission set is defined, you can continue to assign it to new staff, but you’d need to find an admin to add individual permissions to the already defined permission set “circulation services.” Once the admin has added those individual permissions to the set, then the circulation manager could assign the set to new staff.

Andrea mentioned the possibility of a new feature for this use case – Student workers are managed by sub managers who would not have the right, or should not have the right, to adjust their own permissions or the permissions of others but that who do need the ability to assign permissions to student workers only.

Also, it was mentioned that scenario in bullet number one wouldn't prevent a manager of students (with 5 permissions that she can assign to other users) from deleting one and then being unable to assign it after that because of deleting it.

Possible Use Cases for Bullet 2

A user in Interlibrary loan who can assign permissions to other users. His institution has created a permission set called “Interlibrary Loan student,” and that should be the only thing this user can assign to other users. Unless this user has access to Users Permission Sets, they cannot change the Interlibrary Loan Student permission set.

Possible Use Cases for Bullet 3

Implemented a release or 2 ago by the Leipzig team. A button on a user record that you could use to unassign all permissions. We would need the permission to turn it off and on.

Allowing users to remove permissions that they don’t have access to themselves could be dangerous.

Options 1-3 for Morning Glory

Keep this Lotus functionality going forward:
- “users:can assign and unassign permissions to users” for everything
- Security concerns
What we have now:

“users: can assign and unassign permissions to users” only for permissions you already own
users.assign.mutable becomes visible
users.assign.immutable becomes visible
Libraries assign as appropriate

Splitting permissions:

“Users: Can assign and unassign permissions to Users” only for permissions you already own
users.assign.mutable and perms.users.assign.immutable combined into one new visible perm and you can assign perms you don’t have to other users
Libraries assign as appropriate

Option 2 may be the best bet because it would allow for enough granularity. We need to document it very clearly so that everyone understands how this is working.

This is being discussed with the UM SIG on Wednesday

User Interface changes (Bullet 4)

Should we change the User Interface if we will restrict what users can assign?

If I as a user only have the ability to assign permission sets to other users in the permissions that I own, should we change the way the permissions/permission sets list displays so that I would only see the Add Permissions modal?

Should there be a middle ground where by default it only shows the permissions that they can assign, but then there's an option to show all, so they know what to ask to assign to that group if they can’t do it themselves?

Or could we have a “show all” view/flag? People want to know exactly what permissions they have even though they don't have the permission to see the actual permissions or assign them to users.

This would be a new feature.

FOLIO by design does not show the sub permissions because you should not have to worry about what is inside a sub permission.

Or possibly we could consider having a new category in the search and filter to show assignable/unassignable (based on the user who is assigning the permissions), possibly with a flag in the column. This would be in addition to Permission types and permission assignment status filters that are already available. Where Assigned/Unassigned are the permissions the user (not the user doing the assigning) has been given or could be given.

For example, if I’m logged in as a user with 20 permissions, then by default I would just see those 20 permissions, but I would have a “show all” button or option, that I would click to see a list of permissions

Assignable/unassignable (owned/not owned) relates to the user in the system doing the work, but assigned/unassigned relates to the user permissions for the user’s record that you're working on

Erin says they could make some screenshots of the User Interface and bring them to people to take a look.

Erin suggests RA SIG members ask question in the Slack channel if there is something they need clarification about.