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: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Holger Meissner
Sent: Friday, 30 November 2018 1:29 AM
To: koha-devel@lists.koha-community.org
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 <dcook@prosentient.com.au>
Gesendet: Mittwoch, 28. November 2018 01:24
An: Holger Meissner <Holger.Meissner@hs-gesundheit.de>; koha-devel@lists.koha-community.org
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:Holger.Meissner@hs-gesundheit.de]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <dcook@prosentient.com.au>; koha-devel@lists.koha-community.org
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: koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An: koha-devel@lists.koha-community.org
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