Hi Holger, I think you're right about notices being disabled by default. Looking at debian/koha-common.cron.daily I don't see the "--send-notices" flag which is being used by the non-Debian libraries I support.
I think turning off notices will probably be the advice I give from now on, and hopefully that's well received, as this looks like a difficult issue for gaining consensus. Ah, that's a good point about CanBookBeRenewed affecting other things than just autorenewals. (One reason I didn't want to write a patch locally was the possibility of unintended consequences I didn't foresee, so I'm glad that you mentioned that!) I'll have to think more about this one, but for now I'll just recommend that my libraries turn off the notices. Thanks for your input! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Holger Meissner Sent: Wednesday, 5 December 2018 8:20 PM To: [email protected] Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day I seem to have trouble sending emails, let's try plain text this time. I'm sorry if you receive multiple messages. Well, I contributed the original thing (Bug 11577) but not the AUTO_RENEWALS notification. I assumed that this new notification was optional and disabled by default. Seems that I was wrong there? Probably cait disabled it locally for us, before we even noticed :) So just syspref the notification for now? What do you people at ByWater and PTFS Europe say? Did 15705 get pushed by accident, still missing a way to disable notification? It really should be optional. I’m still not convinced it's illogical - if libraries for some reason want to autorenew verbosely. We don't, but I suppose you’d just have to be very careful with the wording of the e-mail. Especially in a big library with title level holds. I can see it being quite annoying in that use case. Here's what I'm worried about: Rearranging the error precedence in CanBookBeRenewed wouldn't just affect autorenewals, it would affect all issues and how they are displayed in opac and in staff client. > If you want to notify patrons when someone places a hold on their loan > so that they can decide to return it out of courtesy, I’d recommend > making adding a different feature for that I think that's actually a great idea! Equal notification for all holds. Yet, it would be confusing if a patron is notified, then logs into opac and can't see the holds they were notified about. Also, I want to see holds in staff client as soon as they are placed. If you don't, then making the error precedence configurable might be a solution. Another wild idea, if really necessary make CanBookBeReturned return multiple reasons. Maybe using a bit field, to speed up the extra work as much as possible and easily check for any combination of renewal errors. Or maybe just using new “too soon and on hold” and “auto too soon and on hold” errors. Regards, Holger Von: David Cook <[email protected]> Gesendet: Montag, 3. Dezember 2018 01:07 An: 'Andreas Hedström Mace' <[email protected]>; Holger Meissner <[email protected]>; [email protected] Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Hi Andreas, Can someone post a patch for your local fix? It’s my intention to write a patch at some point, but I’ve had a number of other tasks occupying my attention lately (as well as being off sick). I’d be happy to test an existing patch though. As the original author of the function, I’d like to hear more from Holger. It looks like Hochschule für Gesundheit sponsored the patch as well? So I’m guessing that the current way it functions must be working for them. I’d hate to break functionality that is working for someone. I’m thinking adding configurability of the ordering of steps might be the best bet. What do you think, Holger? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Andreas Hedström Mace [mailto:[email protected]] Sent: Friday, 30 November 2018 7:54 PM To: David Cook <mailto:[email protected]>; 'Holger Meissner' <mailto:[email protected]>; mailto:[email protected] Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Hi all! In general, I agree with David’s conclusions. We had plenty of confusion from patrons when first implementing autorenewals, and have now fixed it locally. Since we are a fairly large academic library, for popular material there will ususally be several copies of a book, where each of these can fill a placed hold. So sending out an email that it won’t be autorenewed far ahead of the due date to all the patrons doesn’t make much sense, since the hold might be cancelled or filled by another copy by the time it is actually tries to renew (as set by “no renewal before” in the circulation rules). Making these steps configurable could be a viable way forward I believe. Best regards, Andreas ________________________________________ Andreas Hedström Mace Systems Librarian Stockholm University Library Stockholm University 106 91 Stockholm Tel: +46 (0) 8-16 49 17 su.se/english/library/ ________________________________________ Från: <mailto:[email protected]> på uppdrag av David Cook <mailto:[email protected]> Datum: fredag 30 november 2018 00:36 Till: 'Holger Meissner' <mailto:[email protected]>, "mailto:[email protected]"; <mailto:[email protected]> Ämne: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Thanks for your feedback, Holger. Do you currently use autorenewals? I think you might be misunderstanding how it works? The precedence of “on hold > too many > too soon” is illogical for autorenewal in my mind. When the autorenewal daily cronjob runs, it will only send email alerts for “too many” and “on hold”. The most common outcome of the script should be “too soon” as it’s during the normal loan period before the due date, so it really should be the first check. If it’s not “too soon”, then you try to process a renewal. The next step would be checking if you have any renewals left. If not, then it’s “too many”. If you do have renewals left, then you move to the next check, which would be checking for holds. The logical precedence would be “too soon > too many > on hold”. “A patron might decide to return that book earlier if they know someone else is waiting instead of just knowing that it won’t be renewed anymore”. That seems to be a corruption/bleeding of scope for an autorenewal script. If you want to notify patrons when someone places a hold on their loan so that they can decide to return it out of courtesy, I’d recommend making adding a different feature for that (and probably integrate it with recalls which could optionally shorten the due date of the on loan item so the patron has to return it earlier for the person who put the hold on it – recalls is a common feature in other established ILS/LMS systems). “And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now”. Firstly, they don’t currently know that it’s too early, as email notifications don’t go out for “too soon”. Secondly, I have patrons returning their books when they get the “can’t autorenew because there is a hold”, because they think that their book has been recalled even though Koha thinks they actually have several weeks left, because their loan was in fact successfully autorenewed the day before they got the “on hold” email notification. At this point, librarians are getting annoyed at Koha for misleading patrons, and I’m advising librarians to not use the autorenewal function as a result. My options are as follows: 1) Continue warning people that this feature doesn’t work as they expect, which doesn’t look good for Koha 2) Patch the script via the Koha community workflow, which is ideal for developers and librarians 3) Patch the script locally, which is far from ideal, but will make librarians happy I’ve been extremely busy, but it is my intention to submit a patch for this. If there is enough disagreement about the order of steps, perhaps it would be best to make the order of steps configurable. It wouldn’t be a difficult thing to do. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: mailto:[email protected] [mailto:[email protected]] On Behalf Of Holger Meissner Sent: Friday, 30 November 2018 1:29 AM To: mailto:[email protected] Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Thanks for the explanation, David. > Yes, I would like to get the “too soon” error message instead of the “on > reserve” error message if both apply. I’d rather not. If patrons only know it’s too early they will expect a renewal. Which won’t happen, because of the hold we already know about. Why not tell them right away? I would agree if holds were canceled most of the time, but in my estimate they aren’t. > Koha shouldn’t do anything until the threshold for autorenewal (e.g. > September 15 2018), because the item’s status is on loan. How would you implement something like that? The autorenew cronjob can’t do nothing. It has to try and renew everything every time it runs. > In other words, autorenewal should be treated the exact same as manual > renewal. If Person A manually renews Book A on September 1 > 2018 making a new due date of September 15 2018 and Person B puts a > hold on Book A on September 2 2018, nothing would happen until Person A tried > to manually renew Book A on September 15 2018. At that point, Koha would say > they can’t renew because of a hold. I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold. > Currently, people are getting emails telling them they can’t autorenew > their book on September 2 2018 because someone has placed a hold, but this is > a misleading email, because on September 1 2018 their book was autorenewed > until September 15 2018. The email is illogical. I’m probably missing something but I don’t see what’s illogical or misleading about it. I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won’t be renewed anymore. And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now, even if all three apply at the same time. Regards, Holger Von: David Cook <mailto:[email protected]> Gesendet: Mittwoch, 28. November 2018 01:24 An: Holger Meissner <mailto:[email protected]>; mailto:[email protected] Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Hi Holger, Nope, I don’t want to change autorenewal being stopped when a hold is placed. Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply. Here’s my reasoning: 1) Book A is due on September 1 2018 2) Book A is autorenewed until September 15 2018 3) Person B places a hold on Book A 4) Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan. In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold. Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical. It shouldn’t be trying to autorenew because it’s “too soon”. Only when it’s otherwise renewable should we be checking for holds. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Holger Meissner [mailto:[email protected]] Sent: Wednesday, 28 November 2018 4:37 AM To: David Cook <mailto:[email protected]>; mailto:[email protected] Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Hi David, could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour? Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both? What’s the benefit of checking whether it’s too early first? Regards, Holger Von: mailto:[email protected] <mailto:[email protected]> Im Auftrag von David Cook Gesendet: Freitag, 16. November 2018 05:58 An: mailto:[email protected] Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Hi all, I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.) It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written. The first check it makes is for holds and if it finds a hold it returns an error. However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing. I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
