Permissions: Can Create New User
Description
Environment
Potential Workaround
blocks
relates to
Checklist
hideTestRail: Results
Activity
Mike Taylor March 13, 2017 at 12:44 PM
I created a new LIBAPP issue, LIBAPP-157, for the authoring of permission sets.
With that separated out, I believe this one can be closed.
Mike Taylor March 13, 2017 at 12:23 PM
OK, I think we are on the same page here.
From the perspective of the software, permissions are low-level and indivisible, and each govern a single operation – as in this case, users.create governs the ability to create a user and nothing more.
But from the perspective of human users, permissions are high-level and aggregated – as in this case, a "Create Users, with everything necessary to do so" permission.
It will be an application-design task to create appropriate permission groups so that the latter high-level view can be implemented on top of the simple primitives provided by the low-level view. At least, that is how I see it – I don't think we can countenance having the code for reading a record checking "can the user either read or create records"? That kind of disjunction is precisely what permission groups exist for.
Cate Boerema March 13, 2017 at 8:45 AMEdited
Hi Mike. We don't want to expose permissions that give rights to only one operation to the user as we expect it will result in confusion and errors. For example, suppose I gave User A "can edit user" permissions only. I would expect User A to be able to edit users in FOLIO. But, if this permission is defined as you propose, User A would NOT be able to edit user records unless I remembered to _also _ give them "can view users". To avoid these kinds of problems, we'll be grouping base permissions into base permission sets (as defined in the stories). These are what will be exposed as "base permissions" to users. Library administrator users can then group those further into "permission sets". Make sense?
Mike Taylor March 11, 2017 at 9:16 PM
At any rate – I have implemented what I thought this issue was about: now, the New user button is available only to users who have the users.create permission. For users without this permission, the button simply does not appear, and so the pop-up form that it bring into being never arrives.
Mike Taylor March 11, 2017 at 9:13 PMEdited
Reading this in detail, I think we have a very fundamental issue with how permissions work.
In scenario 1 as described above, the "Can Create New User" permission (users.create) actually gives permission to do many other things as well as creating a user – viewing users, editing existing users, and so on.
But my understanding has been that each permission authorises one and only one operation – in this case creating new users. (When we want a single permission to authorise multiple operations, we create the necessary compound permission as a permission group.)
Is this how others have understood it, too?
Details
Details
Assignee
Mike TaylorReporter
Cate BoeremaLabels
Priority
P3
Purpose: Improve permissions handling so that assigned permissions control what options are presented to the user within FOLIO (currently all options are presented and you get an error when you attempt something you don't have rights to). The focus of this story is the Can create new user permission. Other stories will be added for other permissions.
Scenarios:
Scenario
Given User A has been assigned the "Can create new user" permission ONLY
When FOLIO is displayed
Then User A has the following rights:
Users app is visible in Recent Applications Toolbar
Basic user data can be searched and filtered in Users app*
Restricted user data can be searched and filtered in the Users app*
Basic user fields can be viewed*
Restricted user fields can be viewed*
Direct linking to User search, results and details is allowed
User Edit button/icon is visible
Basic user fields can be edited*
Restricted user fields can be edited*
Direct linking to Edit User page is allowed
Create new user button is visible
User creation is permitted
Direct linking to Create User page is allowed
*NOTE: Items with asterisk assume we have implemented the distinction between basic and restricted fields. If we haven't yet done that, we can consolidate.
Scenario
Given User A has been assigned the "Can create new user" permission ONLY
When FOLIO is displayed
Then User A does NOT have the following rights:
Can view permissions assigned to users
Can assign and unassign permissions to users
Settings app is visible in Recent Applications Toolbar
"User permissions" link is visible under Settings > Users
User permission sets can be created, read, updated and deleted
Scenario
Given I don't have rights to direct link to Page A
When I direct link to page A (e.g. I paste the url into my browser)
Then I should see the following message:
Header/Title: Permission Error
Text: Sorry - your user permissions do not allow access to this page.
NOTE: This is an edge case and it doesn't need to be pretty, but we do need to make sure it works so there's no back door to access things you shouldn't be able to access. We're flexible on how we do this.
Scenario
Given User A has been assigned the "Can create new user" permission AND another permission or set
When FOLIO is displayed
Then User A shall have the cumulative set of rights from all assigned permissions
Additional Info: A graphical representation of the rights by base permission can be found in this google sheet. Please note that the scope of the sheet is much larger than this particular story (and even includes some items that are out of scope for v1). Please reference the scenarios in this story for story scope.