Cannot Edit Permissions within Permission Group

Bug #1891375 reported by Erica Rohlfs
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
3.8
Fix Released
Undecided
Unassigned

Bug Description

Version 3.4, 3.5 +

Within the new Angular version of the Permission Group interface (Administration -> Server Administration -> Permission Groups), there is not a way to edit the values of the group's inherited permissions.

For example, (using the out-of-the-box permission group structure) if the System Administrator inherits the Copy_Holds rule from the Staff permission group, Staff only has this permission at branch level and not grantable. If the System Administrator wants to have this ability at the system/consortium level and grantable, there is not a way to re-scope the depth of a permission or to select/deselect grantable.

The current option is to add the same permission to the user group that they already inherited and then scope / set grantable, etc. This leads to duplication of permissions within the interface (and not entirely clear which permission value will take precedence).

Image attached.

Revision history for this message
Erica Rohlfs (erohlfs) wrote :
Revision history for this message
Bill Erickson (berick) wrote :

Hi Erica, I have some work flow questions

1. I can imagine it being useful to see that an inherited permission exists and is superseded by a "closer" permission. What if we tagged the inherited permission as "overridden" in the UI to make it clear it's not active for the selected group?

2. As for creating the overriding permission, the concern is that having to add a new permission as opposed to modifying the existing inherited permission is not intuitive?

Revision history for this message
Jennifer Weston (jweston) wrote :

Hi Bill,
I am working with lots of permission groups this week -- and I can say I do like seeing the multiple entries so I know what was inherited and what was created. This makes documenting each group and it's ancestors/descendants much clearer -- especially if crafting brand new staff groups with increasing levels of permission.

+1 to tagging the inherited permission as "overridden" to clarify which takes precedence would be helpful

tags: added: admin-pages
Changed in evergreen:
status: New → Confirmed
Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

Branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1891375-perm-editor-show-overrides

Adds an icon to indicate when a permission overrides a parent permission. Both version of the permission, the one for the selected group and the one for the most immediate parent group, are still displayed in the list.

Changed in evergreen:
milestone: none → 3.9.1
assignee: Bill Erickson (berick) → nobody
tags: added: pullrequest
Revision history for this message
Terran McCanna (tmccanna) wrote :

I really like the change to the display, I find it much easier to tell what's going on!

My sign off is at: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1891375-perm-editor-show-overrides_signoff

tags: added: signedoff
Revision history for this message
Michele Morgan (mmorgan) wrote :

Makes the permission groups display much clearer for overriding permissions.

Pushed to master, rel_3_9 and rel_3_8.

Thanks Bill and Terran!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.