Summary: | Setting and unsetting the protected flag should be limited to superlibrarian accounts | ||
---|---|---|---|
Product: | Koha | Reporter: | Kelly McElligott <kelly> |
Component: | Patrons | Assignee: | Jake Deery <jake.deery> |
Status: | Needs documenting --- | QA Contact: | Paul Derscheid <me> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | bibliothek, dcook, emily.lamancusa, gmcharlt, jake.deery, kebliss, kyle.m.hall, lucas, martin.renvoize, mspinney, pedro.amorim, rcoert |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: |
Only patrons with superlibrarian permissions will be able to set or remove the "Protected" flag on patron accounts
|
Version(s) released in: |
24.11.00
|
Circulation function: | |||
Bug Depends on: | 26170 | ||
Bug Blocks: | 37360, 37532, 37815 | ||
Attachments: |
Bug 36085: Only superlibrarians can protect patrons
Bug 36085: Only superlibrarians can protect patrons Bug 36085: Only superlibrarians can protect patrons Bug 36085: (QA follow-up) Tidy members/memberentry.pl |
Description
Kelly McElligott
2024-02-13 15:04:17 UTC
+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 |