I don't know exactly how to file this. Koha is growing all the time and new features are always being added, but they are often being added with very little permission granularity. Often the permissions are too broad. For example, the newer pages under additional-contents.pl is under the entire umbrella of one permission for the user, and gives them access to ALL pages, ALL news, and ALL HTML customizations. 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. Maybe there is a bug on this topic already?
We are certainly due a permission clean-up and I there are a lot of bugs when you look for 'permission' that we could put here to make this an omnibus bug. One thing we might want to think about is moving away from the mix of borrowers.flags and the permissions table to give us a better base to order and group permissions. As a topic for discussion, it might be better suited for the mailing list or developer meetings.
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.
(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.
Hi For information, you can have a look at the FOLIO permission system https://docs.folio.org/docs/platform-essentials/permissions/ "FOLIO has a user permissions system that allows for granular control over what users can access in their FOLIO installation. ... By default, a FOLIO installation does not provide roles or permission profiles for library staff. Instead, FOLIO administrators can build their own groups of permissions called permission sets that correspond to their local needs." I love that!
(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.
But... overhauling permissions would take a lot of deliberation and cooperation across a number of Koha devs and I don't see that happening any time soon. Architectural changes like these are some of the hardest to make in Koha due to 25+ years of inertia.
Technically, I suppose we could add a lot more subpermissions to cover more actions, and then maybe just think about improving the top-level permissions...
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.
(In reply to Sally Lodico from comment #8) > 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. That is a very interesting point. I imagine a lot of devs would argue that a tools permission is a better fit for the additional contents generally speaking, but... yeah it's not a change that would've been expected and I don't think it was noted, so good point. Maybe it would've been a good idea to create a new separate permission for it, as then it could've been populated off of the manage system preferences permission. Unfortunately, I think it's a bit late now. Damage done I imagine. That said... it sounds like you're saying you see News and Additional Contents as quite distinct in terms of permissions on an on-going basis not just a historical one?
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?
Actually there already is one: Bug 37849 - Permissions for additional content - HTML Customizations, Pages, News, OPAC, etc