[UXPROD-3614] Permissions Management Improvements for mutable and immutable permissions Created: 16/Mar/22  Updated: 30/Nov/23

Status: In Refinement
Project: UX Product
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: TBD
Reporter: Erin Nettifee Assignee: Thomas Trutt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UIU-2542 Create new permission sets to use mut... In Refinement
Relates
relates to MODPERMS-157 Check assignment permissions for oper... Closed
relates to MODPERMS-182 Migrate more users to perms.assign.im... Closed
relates to MODPERMS-160 Migrate assignment permissions Closed
Development Team: None
PO Rank: 0
Rank: Cornell (Full Sum 2021): R2

 Description   

With Lotus, FOLIO has introduced a new, more granular way of managing permission assignment that is more secure.

We now have three primary permissions involved:

perms.users.assign.mutable
perms.users.assign.immutable
perms.users.assign.okapi

In addition, the mechanism for assigning permissions was changed such that, by default, users can only assign a permission to the other user that they already own.

(Mutable permissions are ones that can change after a module is started up, and are labeled as permission sets in the UI. Immutable permissions are ones that cannot change after a module is started up, and are labeled as permissions in the UI.)

While some sites primarily use an admin user to assign staff permissions, many libraries distribute that role to area managers and have been doing so with the permission ui-users.editperms ("Users: Can assign and unassign permissions to users").

In order to make this permission change transparent for the move from Juniper -> Lotus, developers added perms.users.assign.mutable and perms.users.assign.immutable to ui-users.editperms. That means that those who have the permission set ui-users.editperms in their Lotus instance ("Users: Can assign and unassign permissions to users") will not have their work process changed.

However, we need to evaluate the changes to decide how to use these new controls - whether we should continue to allow people who can assign and unassign perms in the Users app to be able to do it for all permissions, or just permissions they own.

In scope

  • Evaluate the human-readable names proposed in UIU-2542 In Refinement and decide / change what they should be
  • Recommend appropriate changes to naming of ui-users.editperms for Morning Glory
  • Updates to ui-users to allow the new permissions created in UIU-2542 In Refinement to have desired functionality
  • Decide on whether we have enough use cases for "You can only assign permissions you already own" to create a permission just for that and deprecate ui-users.editperms
    • Decide if additional UI changes are needed (such as modifying the add-perms modal such that you can only see permissions that you have the ability to add or remove from other users)- This needs to become a new feature.

Additional Info
perms.users.assign.okapi is used to manage permissions on the system level with Okapi and end-users do not need to assign that permission to other users, so it is not being considered as part of this work. It will remain invisible to reduce additional confusion.

Discussion slidedeck: https://docs.google.com/presentation/d/1axIHIOH8j-k1Hi4xi8yyeCp09APLiGZ_gYJw_TYnBbc/edit?usp=sharing



 Comments   
Comment by Erin Nettifee [ 25/Aug/23 ]

Thomas Trutt see comments on UIU-2542 In Refinement

Generated at Fri Feb 09 00:33:25 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.