Permission group override indicator can be misleading
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Undecided
|
Unassigned |
Bug Description
Bug https:/
- Depth is looked at first in ascending order (0 to 3), so broadest depth wins
- Grantability is looked at in descending order (1 or 0) so true will override false, but only when depth is assigned at the same level
I know in most (if not all) cases, the child group would have the permission assigned at the broader depth, so it generally won't be an issue, but I think the override symbol should be based on the depth of the permission instead of how it is assigned to the group.
A couple examples:
Permission for PATRON_
- Administrator (parent): depth=0, grantable=true
- Local Admin (child): depth=1, grantable=false
Using a Local Admin account, I had the ability to override the patron exceeds fines exception for any patron in the consortium, and I could grant the permission to staff accounts. In the permissions list, the Local Admin permission is shown to override the inherited Administrator permission, but the permission was following the rules assigned at the Administrator level.
Permission for ADMIN_BOOKING_
- Administrator (parent): depth=1, grantable=false
- Library Manager (child): depth=2, grantable=true
Using a Library Manager account, I could create a booking resource for any branch in the system and was not able to grant the permission to other staff. In the permissions list, the Library Manager permission is shown to override the inherited Administrator permission, but the permission was following the rules assigned at the Administrator level. Screenshots attached.