Bug 18787 - Create permission profiles for staff users
Summary: Create permission profiles for staff users
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 6223 31184 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-06-12 14:19 UTC by Séverine Queune
Modified: 2025-11-05 22:55 UTC (History)
10 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Séverine Queune 2017-06-12 14:19:34 UTC
It would very useful if we could define different permission profils, depending on the library uses, to prefill permissions.

For example, in our site, we could have :
  - a "catalog profil" to edit records and items
  - a "subscription profil" because there is a team which works specifically on periodical publications
  - a "circulation profil" because some of us don't work directly with patrons so they don't need to access to the Patron and Circulation module (but they could borrow books for themselves)
  - a "team manager profil" because they have permission to see acquisition budget for all their team
  - etc.

It would be an easier way to define permissions for a new staff user and a way to be sure all the accounts are identically set.
Comment 1 Katrin Fischer 2018-05-17 22:49:30 UTC
*** Bug 6223 has been marked as a duplicate of this bug. ***
Comment 2 Séverine Queune 2021-03-09 07:14:11 UTC
Just discovered this plugin, but not tested yet.
https://github.com/bywatersolutions/koha-plugin-batch-permissions-modifier
Comment 3 Alexander Wagner 2023-08-22 14:42:57 UTC
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.
Comment 4 Marie-Luce Laflamme 2024-01-31 23:08:05 UTC
+1. This is a great idea!
Comment 5 Alexander Wagner 2024-02-01 12:17:48 UTC
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.
Comment 6 David Cook 2024-04-23 23:19:39 UTC
*** Bug 31184 has been marked as a duplicate of this bug. ***
Comment 7 David Cook 2025-03-26 04:20:43 UTC
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.)
Comment 8 David Cook 2025-03-26 04:53:45 UTC
(In reply to David Cook from comment #7)
> 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.)

And actually... I suspect we could leverage bug 30623 here as well...
Comment 9 David Cook 2025-11-05 03:00:33 UTC
Thinking about this again... and there really are a variety of options.

1. Default permissions by patron category at patron create time
2. Permission profiles chosen specifically at patron create time
3. Permissions by patron category that get merged into individual patron permissions at authorisation check time
4. Permissions by profile/role that get merged into individual patron permissions at authorisation check time
5. Others?

Default permissions at patron create time would be easiest and the first one where it's done by patron category would be the easiest because it would require the fewest changes. But... lots of libraries have a single "Library Staff" category which wouldn't really fit the needs of different staff members performing different roles that need different permissions.
Comment 10 David Cook 2025-11-05 03:14:53 UTC
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.
Comment 11 David Cook 2025-11-05 03:19:47 UTC
Of course, the backend could be complicated, if we wanted to change how we do permissions a bit. Like would we map flags and subpermissions, or would we use a more expressive way of recording permissions per role?

I think @Kyle had a bug report for that years ago but not sure what happened to it. I think it may have scared people, since permissions are such a central part of Koha, and change is scary. Not sure.
Comment 12 David Cook 2025-11-05 03:25:39 UTC
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.
Comment 13 Lisette Scheer 2025-11-05 18:51:37 UTC
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.
Comment 14 David Cook 2025-11-05 22:55:15 UTC
(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.