Bug 33448 - staffaccess permission needs to have 'permissions' removed from description
Summary: staffaccess permission needs to have 'permissions' removed from description
Status: REOPENED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-04-07 23:43 UTC by Christopher Brannon
Modified: 2024-05-02 15:06 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2023-04-07 23:43:12 UTC
staffaccess no longer controls whether a staff member can modify user permissions.  That is now controlled by the permissions permission.

The staffaccess description needs to be updated.
Comment 1 Katrin Fischer 2023-04-08 16:06:18 UTC
The description is not really false. 

When you don't have staffaccess, you can't change other staff member's permissions. I just verified this by giving myself all permissions but superlibrarian and staffaccess. I am not able to change permissions, but get prompted for authentication when I try.

We could probably do a little better and display a nicer error with an explanation, like we do on the password reset page.
Comment 2 Christopher Brannon 2024-05-02 15:06:04 UTC
I would like to revisit this.  Staffaccess, which lists modifying permissions as one of it's purposes is not accurate.  If I set it, the staff member does not have this ability (which I am glad).  I need to be able to give staff permission to change usernames and passwords without giving them keys to the whole system.

The modify permissions should be removed.  The permissions setting is what really allows this, and is independent of staffaccess.  As is, these settings are confusing.  Removing modify permissions from staffaccess seems to be the logical choice.  If not, please provide an explanation why it needs to remain on the description of this setting.