I’ve taken another look at C4::Circulation::CanBookBeRenewed(), and it seems that function could benefit from functional decomposition. The function is about 180 lines which seem too fragile to touch. Jonathan has posted a patch to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 but there seems to be a fair amount of disagreement with its approach to solving the problem. That said, without refactoring C4::Circulation::CanBookBeRenewed(), changing ./misc/cronjobs/automatic_renewals.pl seems like the only way forward. But changing ./misc/cronjobs/automatic_renewals.pl means making too many assumptions about what to do. I don’t see a practical way forward without refactoring C4::Circulation::CanBookBeRenewed(), but it’s such an important and multi-factor part of Koha that I’m reluctant to touch it. There do seem to be a fair number of tests in t/db_dependent/Circulation.t but I don’t think I can commit the time/effort to this issue at the moment. 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 McGowan, Janet Sent: Tuesday, 11 December 2018 4:02 AM To: Holger.Meissner@hs-gesundheit.de Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. Having said that there are many benefits to the --send-notice functionality - the end user is notified about the reason why a material is renewed or otherwise - so ideally we would like to be able to use this separate autorenewal notification. I believe the community bug for this is https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 but in a few brief tests I don't believe it totally fixes the problem, I'm afraid I haven't had a chance to test the fix properly yet though. -Janet Janet McGowan <https://www.ptfs-europe.com/> Director of Operations Phone: +44 (0) 1483 378728 Mobile: +44 (0) 7985 431 266 Email: <mailto:janet.mcgowan@ptfs-europe.com> janet.mcgowan@ptfs-europe.com <https://www.ptfs-europe.com/> www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com <mailto:info@ptfs-europe.com> On Mon, 10 Dec 2018 at 16:47, Holger Meissner <Holger.Meissner@hs-gesundheit.de <mailto:Holger.Meissner@hs-gesundheit.de> > wrote: On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:janet.mcgowan@ptfs-europe.com <mailto:janet.mcgowan@ptfs-europe.com> > wrote:

Our feedback from customers has been that the user only needs to be informed that the autorenewal cannot take place at the point that the renewal would take place (ie at the point that the No renewal before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before? We actually use OPACUserJS to hide that setting. Regards, Holger _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> 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/

Just letting folk know that I've refactored the logic for the autorenewals at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22333. It's the exact same behaviour as before but it deduplicates some code by using an existing function and it just writes it in a way that is more readable/maintainable. Locally, I've also duplicated a section of the code into automatic_renewals.pl (and wrapped it with a system preference) so that the first thing checked is the earliest renewal date and if it's in the future, then I skip CanBookBeRenewed all together (so as to avoid the issues with holds, max checkouts, etc causing confusing email notices to go out). After some local testing, I'll post a patch with that too, which hopefully will meet everyone's needs between the current behaviour and what I (and some others) consider the more logical behaviour. 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: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Holger Meissner Sent: Tuesday, 11 December 2018 9:30 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day On Mon, Dec 10, 2018 at 06:02 PM McGowan, Janet <mailto:mailto:janet.mcgowan@ptfs-europe.com> wrote:

Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1.

I disagree. For example, we set "no renewal before" to 11 days and send PREDUE 10 days in advance. We locally prevent patrons from changing that setting. Nobody complained about it so far. A more elegant and more user-friendly solution would be a feature enforcing PREDUE <= no renewal before. Or maybe just a warning popup for spam producing values. Regards, Holger _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/