https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18787 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|16.11 |master -- 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=18787 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |conan@lugmen.org.ar --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- *** Bug 6223 has been marked as a duplicate of this bug. *** -- 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=18787 e.betemps <e.betemps@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |e.betemps@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18787 Amanda Campbell <acampbell@hmcpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acampbell@hmcpl.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18787 Alexander Wagner <alexander.wagner@desy.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexander.wagner@desy.de --- Comment #3 from Alexander Wagner <alexander.wagner@desy.de> --- Indeed it would be nice to have something along the lines of unix-groups that assign certain rights. E.g. I could define what cataloguers can do or the ILL staff and then assign people to be cataloguer and/or ILL staff easily. Indeed, I spent some time to fiddle out that this seems not to exist (yet). In view of Bug 6223 also the term `roles` comes to mind. The https://github.com/bywatersolutions/koha-plugin-batch-permissions-modifier plugin Séverine mentioned goes in this direction indeed and populates permissions from a template user to all users on a given patron list. It works pretty well as far as I tested it, just in "auto" mode it seems not always to trigger. (IOW I had to run it manually from time to time to propagate permissions.) I'll have to check what happens if some user shows up in two lists, though. It doesn't look like this is meant to be. Configuration might get a bit ugly as one has to add template patrons and lists to handle all set up by bare numbers. -- 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=18787 --- Comment #5 from Alexander Wagner <alexander.wagner@desy.de> --- Diving into the mentioned plugin I found indeed that it assumes each patron gains only one set of permissions (iow you can not be in more than one group). For this reason I came up with a small perl script than will handle permission setup for j2k. This script basically reads an input file giving the name of the role someone should have and her cardnumber. It will then create a patron list for the roles, add patrons to the list (for easy reference) and add permissions accordingly. This script could need a bit of improvement for general use. E.g. an immediate thing would be to move the hard coded hash for permissions to some source read in, and probably for koha purists the idea to have files around that implement the functions are not that common. (It's just easy for me to handle those files in git within j2k.) But maybe one could build upon it. -- 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=18787 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- Thinking about this one again... Technically, you could do a version of this using IntranetUserJS. On the /cgi-bin/koha/members/member-flags.pl page you could have a little dropdown and when you select the desired profile it could check the necessary boxes for you. It would be a very light touch semi-automated solution. I think a community supported version could have a database table for storage, Vue UI for CRUD of profiles, and then on /cgi-bin/koha/members/member-flags.pl still use the Javascript idea to pre-select boxes based off the profile. (Alternatively, you could have some other mechanism for doing the update, but it's an easy 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=18787 Lisette Scheer <lisette@bywatersolutions.com> 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=18787 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- Thinking about where we'd need to update... I think ultimately a user's permissions get returned by "getuserflags" in C4/Auth.pm. The flags are used in "get_authz_from_flags" in Koha/Auth/Permissions.pm to the "CAN_user_$module_$subperm" mappings, and "haspermission" in C4/Auth.pm checks $flagsrequired (e.g. { self_check => 'self_checkin_module' } ) against $flags from "getuserflags". -- I actually have a user audit tool in my local Koha that shows you a table/matrix of your users and their permissions, and that also uses C4::Auth::getuserflags() to get a user's permissions, so that would dovetail well too... -- In theory, adding a simple role-based permission model might actually not be too hard on the backend... Looking at ./members/member-flags.pl it seems that the permissions shown are derived more directly from the DB, so that's good. That said, I think we'd want a way to show patrons their "effective permissions" too. In the end, I think the UI/UX is probably going to be the hardest part of this change actually. -- 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=18787 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- I think this would be an interesting one to work on, but I think it would probably require a handful of devs to collaborate on / agree on the design. I think it would be too risky for one person to write up the whole thing only to find that it doesn't get any traction. -- I don't have any sponsorship for this one, but being able to provide default permissions by patron category has been on my backlog TODO list for over 12 years now, so it would be great to find a solution in some way, shape, or form. -- 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=18787 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20813 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Lisette Scheer from comment #13)

Martin and I were talking recently and I'm hoping to work together with folks at KohaCon for a rough spec of what all needs to get done that we could finalize and try and finish at/hackfest 2026. I added a lightning talk about what Martin and I came up with to help let people know it's a discussion we'd like to start.

Kyle's bug is 20813. I filed 2 related bugs at KohaCon 2024 that are linked on 20813 that are the main to do's that were blocking Kyle's work.

Thanks for that, Lisette. We'll certainly need to put our heads together I reckon. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.