https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170
--- Comment #11 from David Cook <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
