With the new enhancement, 26170, add protected status to patrons, this allows any patron to be updated/edited to be a 'protected patron'. Staff with 'edit borrowers' permission will be able to update this status. I believe there should be a permission to allow for this field to be updated/edited within Koha.
+1 for adding a permission!
Mmm that's an interesting one. My original vision for this was to have it manageable only be superlibrarians (or no web users at all even). It looks like Magnus thought about a permission for changing the protected flag in comment 14 of bug 26170. The hard part about adding a permission is then who is allowed to set that permission? (Sort of a "who watches the watcher" scenario.)
At the hackfest in Marseille we had a long discussion about a potential new permission system based on CRUD and objects. Having a permission for a single field goes a bit beyond that. I'd be interested to hear about the use case for needing the extra protection here. Are you worried that staff will remove the protected status willingly?
Yes, having that extra layer of protection with a permission.
See: https://chat.koha-community.org/koha-community/pl/bnfop47u8ifauf4gpnby4rdd8y It would be nice to have a discussion on some use-cases before deciding which direction to take on this bug. Is it because we are worried librarians might erroneously pick the wrong option for their needs, or that the labelling of the options in memberentry.pl are too vague? Perhaps rather than a permission, we just need better documentation and in-line information?
As I understand the protected status is preferred to administrative system users like sip2, api, selfcheck etc so that my colleagues at the counter cannot delete them accidentally. For standard patrons (which should not be protected in my opinion) a deletion cannot be done by accident, as there is always an inquiry like 'Are you sure ...' Therefore I would suggest that the protect flag should have permissions bound to it or even just be allowed to be set by superlibrarians.
If I understand, then, the use case for this is really centred around superlibrarians protecting borrowers that are necessary for concurrent integrations to work? If this is so, I think cait's suggestion is probably optimal. It's what I like as well, so unless anyone objects, that's the route I will take. Thanks all for your input!
I am not sure I made one :D But do you mean tying to superlibrarian?
That's correct cait, and I meant David Cook's comment rather, about using superlibrarian..! Apologies :-) I'll write a patch this afternoon
All good!
Created attachment 169127 [details] [review] Bug 36085: Only superlibrarians can protect patrons A drive-by patch which hopes to resolve bug 36085 by only allowing superlibrarians to protect or unprotect patrons. Test plan: a) prepare two koha staff users: 1) a superlibrarian 2) a user that only has permission to edit patrons b) when logged in as the user prepared in step a2 (non-superlibrarian), then go to edit any patron *) note how you can set the protected yes/no radios c) apply the patch d) repeat steps a-b as this same user *) note how you can now no longer see the protected yes/no radios e) log in as the user prepared in step a1 (superlibrarian), then repeat steps a-b f) note how the protected yes/no radios are back
A quick fix to this solution, until we have had time to think about how we want to handle these kinds of permissions in future..! :-)
Created attachment 169129 [details] [review] Bug 36085: Only superlibrarians can protect patrons A drive-by patch which hopes to resolve bug 36085 by only allowing superlibrarians to protect or unprotect patrons. Test plan: a) prepare two koha staff users: 1) a superlibrarian 2) a user that only has permission to edit patrons b) when logged in as the user prepared in step a2 (non-superlibrarian), then go to edit any patron *) note how you can set the protected yes/no radios c) apply the patch d) repeat steps a-b as this same user *) note how you can now no longer see the protected yes/no radios e) log in as the user prepared in step a1 (superlibrarian), then repeat steps a-b f) note how the protected yes/no radios are back Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Created attachment 170773 [details] [review] Bug 36085: Only superlibrarians can protect patrons A drive-by patch which hopes to resolve bug 36085 by only allowing superlibrarians to protect or unprotect patrons. Test plan: a) prepare two koha staff users: 1) a superlibrarian 2) a user that only has permission to edit patrons b) when logged in as the user prepared in step a2 (non-superlibrarian), then go to edit any patron *) note how you can set the protected yes/no radios c) apply the patch d) repeat steps a-b as this same user *) note how you can now no longer see the protected yes/no radios e) log in as the user prepared in step a1 (superlibrarian), then repeat steps a-b f) note how the protected yes/no radios are back Signed-off-by: Jan Kissig <jkissig@th-wildau.de> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Created attachment 170774 [details] [review] Bug 36085: (QA follow-up) Tidy members/memberentry.pl
Are we OK that this change only applies to the GUI, but not to the REST API? What about the patron import?
Pushed for 24.11! Well done everyone, thank you!
Yes, we could probably do with a follow-up bug for this. I'll create one.
See bug 37815
Enhancement wont be backpoted to 24.05.x