https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35693 --- Comment #2 from Christopher Brannon <cbrannon@cdalibrary.org> --- I think that is a great idea. Also, I think maybe the best approach to something of this nature is creating a foundation framework for this that new features can use and existing features can hook onto as they are improved. I don't want people to look at this as a major overhaul to existing permissions. This should be something we can create the structure for and then move things over to as we move forward. Otherwise, I fear that developers are going to look at this as a daunting task, and too big to take on, especially as more and more features are continually developed and added on to Koha. -- 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=35693 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Christopher Brannon from comment #0)

I am hoping that Koha will start thinking more about roles in the library, and allowing us to give specific people access to specific pages, customizations, etc. This goes even further with who can override things. We don't have a lot of control over who can do what specific things.

I think that you make a very good point, but Koha developers are a fairly loose group which support a variety of different libraries, and I think most developers have never worked as librarians themselves (with the exception of a few of us). Change usually comes from starting with one developer/vendor and then building support across the group. Personally, most of my (many) libraries have very small staff sizes, and I haven't heard any complaints around permissions (except for the latest one about requiring "edit_borrowers" to search/list borrowers). So I'm unlikely to get sponsorship for such a change. But I imagine there are other vendors who support libraries with larger staffs who would be more likely to get that kind of sponsorship. In the meantime, something that could be helpful is libraries coming up with a list of "personas" and "scenarios". These are useful elements of system design. Something basic like "Joe is a collection development librarian" (persona). The collection development librarian "needs to search the catalogue" (scenario), "needs to update only certain allowed lists" (scenario), "needs to update only collection development HTML pages" (scenario). Basically just outlining the hypothetical people and the things they need to do.

From there the developers can start working out how we can technologically allow those people to do those scenarios.

-- 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=35693 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35693 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35693 Miranda Nero <mnero@oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mnero@oslri.net -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35693 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Mathieu Saby from comment #4)

Hi For information, you can have a look at the FOLIO permission system https://docs.folio.org/docs/platform-essentials/permissions/

This doesn't really look too different from Koha, in my opinion. I quite like AWS's IAM policies which essentially boils down to "subject", "verb", "object", and "condition". X subject can perform Y action on Z object when C condition is met. Each service/module has a list of actions, and these actions are where you get a lot of the granularity. But as Christopher was saying... if you're able to define the "object" or the "condition", you can make it so that X subject can only Y update an existing Z news item. -- Koha permissions typically are only checked at page load time, although I think there are a couple that are checked at action time. -- 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=35693 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_rfc -- 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=35693 Sally Lodico <Slodico@knoxlib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Slodico@knoxlib.org --- Comment #8 from Sally Lodico <Slodico@knoxlib.org> --- I understand how complicated--and expensive--it would be to change Koha's permission system, but Christopher's point about the permissions for additional-contents.pl needing to change seem to have been lost to that bigger conversation. These particular settings, having been moved from System preferences to Tools using the same permissions as the existing News feature is allowing people without the appropriate training or authority to edit things they have no business editing. They couldn't do it before because they did not have permission to edit the System preferences. If someone does not have permission to access a feature before a new development moves or changes something, they shouldn't have access to that feature after. -- 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=35693 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think a separate permission for HTML customizations could still be added now and even if we can't populate it only from the general one, libraries will again be able to adjust at least. But can you please file a separate bug and link it to this one? -- 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=35693 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m --- Comment #12 from Lisette Scheer <lisette@bywatersolutions.com> --- I think this would be a good topic for the next development meeting. Personally I think a role based access control (rbac) similar to the patron permissions plugin we have with the option to set on the individual level if there were niche permission sets would be great. I also think something like Object (item) []View []Edit []Delete []Add []View all branches []Edit all branches []Delete all branches []Add all branches type granular permissions would be more what the bigger libraries we've talked to would like to see. You could set a role/persona with the permissions for example: Circ staff -View all items -Edit items at my branch and assign folks to a role/persona to grant those permissions, but another example: cataloger: view all branches, edit items at my branch, delete items at my branch, add items at my branch. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 Revamp user permissions system (currently failed qa) has a number of bugs it depends on that I filed last year as prerequisites to fixing the issues outlined on that bug in it's current state. -- 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=35693 --- Comment #14 from Lisette Scheer <lisette@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #13)

I wonder how we could best factor library groups into the permission system or if "mine" should always be "home library and all libraries within my group"?

From the type of controls I could see consortia wanting, probably something like my above example +

[]View all branches in group []Edit all branches in group []Delete all branches in group but gosh that just adds even more to keep track of. -- 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=35693 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (In reply to Lisette Scheer from comment #14)

(In reply to Katrin Fischer from comment #13)

...

I wonder how we could best factor library groups into the permission system or if "mine" should always be "home library and all libraries within my group"?

From the type of controls I could see consortia wanting, probably something like my above example +

[]View all branches in group []Edit all branches in group []Delete all branches in group

but gosh that just adds even more to keep track of.

I'm not sure I'm understand this. What I was thinking of was a condition where you could specify something like "all_libraries", "my_library_groups", "my_library" or something like that. So for something like "List borrowers" you'd add the relevant condition (with the default probably being "all_libraries"). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.