https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41845 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #0)

In the current permissions, there's something that *really* bugs me : the mix of permissions that "allow" and permissions that "restrict".

I often create staff accounts as part of the set up we do for new clients and for non-superlibrarians catalogers, I always have to remember to check everything in cataloging EXCEPT that one annoying permission that restricts the subfields (SubfieldsToAllowForRestrictedEditing).

I was wondering if it was possible to take this into account when revamping the permissions.

That's a good point. The way it's done currently drives me a little crazy. Going forward, I do think we need both "allow" and "deny" (or "restrict") permissions, but they need to be separated in a way the effective of the permission clear. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41845 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #2)

I think what bugs me most is that when I check the main "Cataloging" permission (editcatalogue), it also checks the restrictive permission (edit_items_restricted) which means that you think the person has all permissions in cataloging, but in fact they don't.

Oh wow... that is really bad. I've never noticed that before as I don't have many libraries using the syspref SubfieldsToAllowForRestrictedEditing. But yikes! That has to be a bug. And yet... yeah... that really exposes just how bad that permission is designed. It could be improved a bit so that if you have the full editcatalogue permission it doesn't apply the restriction (like how it doesn't apply the restriction to superlibrarian) but still... not good.

I'm not sure how the revamp will affect the UI, but I think that if continue to have restrictive permissions, if you check the "main" permission of a group, it should NOT include the restrictive permissions (i.e. checking editcatalogue should check everything in that section EXCEPT edit_items_restricted)

Well, the issue isn't really with "edit_items_restricted" being checked, because if you have full editcatalogue permission, you don't have the subpermission stored in the database. It's just an implied subpermission given you have the full top-level permission. I agree though that someone with full "editcatalogue" permission shouldn't have "edit_items_restricted" apply to them. I don't know that a "restriction" category would necessarily make sense since the restrictions wouldn't be grouped in any other way other than being restrictions... Personally, I would love to see "policies" that allow/deny actions, which could then be attached to individuals or patron categories. I could imagine some stock policies like "cataloguer" which people could then tailor, and "limited_cataloguer" could be made and have "edit_items_restricted" added. But then how to categorise those permissions vs restrictions in whatever hypothetical editor we came up with... But yeah... it's the permission/subpermission inheritance thing which is really the problem here... I'm not sure how to solve this one with our current permission system. I really dislike that things like "edit_items_restricted" and "view_borrower_infos_from_any_libraries" exist. We need to have more of a think about how we can restructure these... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41845 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41845 --- Comment #6 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- For the edit_items_restricted problem, there is an "easy" workaround but annoying to remember: I usually check the full cataloging permissions (editcatalogue), it opens all the subpermissions, then uncheck edit_items_restricted. It's probably not something system librarians come across very often either. I do a lot of it because we include setting up the first staff accounts in our Koha configuration for new clients. So for every new client, I create between 1-30+ staff accounts. I never voiced my annoyance with edit_items_restricted before because it's annoying but easily circumventable (?). But in the context of a revamp, I think we should think about things like that and not mix permission-types or mix them in an intelligent way. This is the main reason for this bug report. I already mentioned this to Lisette to be included in the revamp, but we decided to open a bug to make sure we don't forget and gather ideas from the larger community. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41845 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |20813 Depends on|20813 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 [Bug 20813] Revamp user permissions system -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.