This is related to bug 6506. The MarkIssueReturned sub of Circulation.pm contains the comment: # The default of 0 does not work due to foreign key constraints # The anonymisation will fail quietly if AnonymousPatron is not a valid entry As noted on bug 6506, this is unacceptable. Severity cloned from that bug. This is a guess, but I surmise that how to test is to enable privacy, check out a book, return that book, and see if the book is in your borrowing history. If it is, that's a fail. If it isn't, that's a pass.
Created attachment 37617 [details] [review] Bug 9942: Make Koha fails if privacy is not respected If a patron has requested anonymity on returning items and the system is not correctly configured (AnonymousPatron no set or set to an inexistent patron), the application should take it into account and not fail quietly. This patch is quite radical: the script will die loudly if the privacy is not respected. To be care of the bad "Software error", some checks are done in the updatedatabase to be sure the admin will be warned is something is wrong in the configuration. Test plan: 1/ Test the updatedatabase entry: a. Turn on OPACPrivacy and set AnonymousPatron to an existing patron => You will get a warning b. Turn on OPACPrivacy and set AnonymousPatron to 0 or '' => You will get a warning c. Turn on OPACPrivacy and set the privacy to 2 (Never) for at least 1 patron Turn off OPACPrivacy => You will get a warning d. In all other cases you will get no error 2/ Test the interface a. Turn on OPACPrivacy and set the privacy to 2 (Never) for a patron b. Now you can turn off OPACPrivacy or keep it on, behavior should be the same c. check an item out the patron d. Check the item in using the check out table => fail e. Check the item in using the Check in tab => fail (not gracefully). Note that the software error could appear on other pages too.
Hi, 1/ Is ok, updatedatabase gives proper warnings/messages 2/ d. You get 'Not checked out' e. You get 'Unable to check in' Both fails to check in, but no indication of reason to failure. Is that the expected outcome? Test runs Ok
It could be improved, but the main goal of this patch is to guarantee the anonymity.
Created attachment 40394 [details] [review] [SIGNED-OFF] Bug 9942: Make Koha fails if privacy is not respected If a patron has requested anonymity on returning items and the system is not correctly configured (AnonymousPatron no set or set to an inexistent patron), the application should take it into account and not fail quietly. This patch is quite radical: the script will die loudly if the privacy is not respected. To be care of the bad "Software error", some checks are done in the updatedatabase to be sure the admin will be warned is something is wrong in the configuration. Test plan: 1/ Test the updatedatabase entry: a. Turn on OPACPrivacy and set AnonymousPatron to an existing patron => You will get a warning b. Turn on OPACPrivacy and set AnonymousPatron to 0 or '' => You will get a warning c. Turn on OPACPrivacy and set the privacy to 2 (Never) for at least 1 patron Turn off OPACPrivacy => You will get a warning d. In all other cases you will get no error 2/ Test the interface a. Turn on OPACPrivacy and set the privacy to 2 (Never) for a patron b. Now you can turn off OPACPrivacy or keep it on, behavior should be the same c. check an item out the patron d. Check the item in using the check out table => fail e. Check the item in using the Check in tab => fail (not gracefully). Note that the software error could appear on other pages too. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Updatedatabase works as described On staff, if don't have correct settings for anonymity it's impossible to check-in (with OPACPrivacy on) No errors
Created attachment 40682 [details] [review] [PASSED QA] Bug 9942: Make Koha fails if privacy is not respected If a patron has requested anonymity on returning items and the system is not correctly configured (AnonymousPatron no set or set to an inexistent patron), the application should take it into account and not fail quietly. This patch is quite radical: the script will die loudly if the privacy is not respected. To be care of the bad "Software error", some checks are done in the updatedatabase to be sure the admin will be warned is something is wrong in the configuration. Test plan: 1/ Test the updatedatabase entry: a. Turn on OPACPrivacy and set AnonymousPatron to an existing patron => You will get a warning b. Turn on OPACPrivacy and set AnonymousPatron to 0 or '' => You will get a warning c. Turn on OPACPrivacy and set the privacy to 2 (Never) for at least 1 patron Turn off OPACPrivacy => You will get a warning d. In all other cases you will get no error 2/ Test the interface a. Turn on OPACPrivacy and set the privacy to 2 (Never) for a patron b. Now you can turn off OPACPrivacy or keep it on, behavior should be the same c. check an item out the patron d. Check the item in using the check out table => fail e. Check the item in using the Check in tab => fail (not gracefully). Note that the software error could appear on other pages too. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Updatedatabase works as described On staff, if don't have correct settings for anonymity it's impossible to check-in (with OPACPrivacy on) No errors Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 40683 [details] [review] Bug 9942 [QA Followup] - Add test and alert to returns.pl
Patches pushed to master. Thanks Jonathan!
Pushed to 3.20.x will be in 3.20.2
Pushed to 3.18.x will be in 3.18.09
Contains string changes, holding till 3.16.14