[Koha-bugs] [Bug 26170] Create "system" patrons that cannot be (easily) deleted via the web UI

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Jun 14 01:35:35 CEST 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170

--- Comment #11 from David Cook <dcook at prosentient.com.au> ---
(In reply to Magnus Enger from comment #10)
> (In reply to David Cook from comment #9)
> > It lingers in the back of my mind, but it's not on my list of priorities, so
> > I haven't thought of it much in years :/.
> 
> Any preferences on how to do it?

I'd need to think about it more. 

Reading back through comments, I realize that it's not just "deleting" that
we'd want to prevent, but also "modifications" to things like the permissions,
password, and userid. 

In that sense, the most likely scenarios seem to be that you'd create a normal
user, set all the details, and then lock/protect them once you've set them up
as desired. And only a superlibrarian can lock/unlock or protect/unprotect.
(RBAC would make this much easier but alas.)

For my purposes, I'd prefer for no one to be able to unlock/unprotect them via
the web UI, but that's not practical for people who don't have backend support.
Maybe we could include a koha-conf.xml item to also enable/disable the
lock/unlock web interface. We could default it to "on", and then backend admins
like myself could turn it off where appropriate. 

This is probably easiest implemented by adding a Boolean column to the
borrowers table. 

A special "extended patron attribute" could be used, but that seems a bit
hacky, and we'd then have to look at securing the patron attributes from
changes too (on both the staff interface and OPAC). I think better to have a
dedicated schema change.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list