Bug 20360 - Auto-Renew notices send in advance of No Renewal Before period
Summary: Auto-Renew notices send in advance of No Renewal Before period
Status: RESOLVED DUPLICATE of bug 19014
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: 17.05
Hardware: All All
: P5 - low normal with 1 vote (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-07 22:13 UTC by Andrew Fuerste-Henry
Modified: 2019-12-31 15:14 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2018-03-07 22:13:00 UTC
Koha sends auto-renew notices for failed renewals before the period defined by the No Renewal Before value in the circulation rule. This results in a confusing and premature notice.

To replicate:
1: Set up a circulation rule that makes the item due more than 2 days in the future, allows auto-renewals, and has a No Renewal Before value of 1
2: Check out an item corresponding to the circ rule created
3: Run the auto-renew cron. The item will not renew and no notice will be generated because the issues table shows it is too soon to perform an auto-renew.
4: Plase a hold on the item for another patron
5: Run the auto-renew cron again. A notice will be generated that the item could not be renewed because there is a hold, even though the item due date is still multiple days off, meaning the item is outside of the No Renewal Before period
Comment 1 Andrew Fuerste-Henry 2018-03-07 22:18:15 UTC
An auto-renewal notice is sent out if issues.auto_renew_error shows a new value other than "too soon." Values such as "too many" or "reserve" take precedence over "too soon."
Comment 2 Jess Tobin 2018-03-09 22:20:18 UTC
This really is a problematic bug. Our patrons are used to seeing a notice telling them that they've reached the max number of renewals...once they've reached that limit, not the day after their final successful renewal. It's also an issue for us with holds--Patron A will receive a failed renewal notice the day after Patron B places a hold on a book checked out to Patron A, regardless of how many days remain before the actual due date of book for Patron A. We're a small library; I can only imagine the confusion that would result for patrons at a large public library, for example. Many thanks in advance to anyone who is able to put some effort toward fixing this bug!!
Comment 3 Jonathan Druart 2018-03-26 16:51:55 UTC
Please take a look at bug 19014, I think it fixes the issue you face.
Comment 4 David Cook 2019-01-10 03:53:18 UTC
(In reply to Jonathan Druart from comment #3)
> Please take a look at bug 19014, I think it fixes the issue you face.

Happy to get more people looking at bug 19014. 

"It's also an issue for us with holds--Patron A will receive a failed renewal notice the day after Patron B places a hold on a book checked out to Patron A, regardless of how many days remain before the actual due date of book for Patron A."

I've been hearing about this one a lot and would love to find a solution to it.
Comment 5 David Cook 2019-02-14 05:47:10 UTC Comment hidden (obsolete)
Comment 6 David Cook 2019-02-14 05:50:49 UTC
I have a solution which will live in the automatic_renewals.pl script.

It'll essentially borrow the code from #22333 but put it into automatic_renewals.pl wrapped with a system preference so that the first thing automatic_renewals.pl does is check if it's too early to renew (ie consult No Renewal Before or fallback to checking if it's before the due date).

I think this should be a good solution.

Just trialing it locally first.
Comment 7 Björn Nylén 2019-03-18 13:10:58 UTC
(In reply to David Cook from comment #6)
> I have a solution which will live in the automatic_renewals.pl script.
> 
> It'll essentially borrow the code from #22333 but put it into
> automatic_renewals.pl wrapped with a system preference so that the first
> thing automatic_renewals.pl does is check if it's too early to renew (ie
> consult No Renewal Before or fallback to checking if it's before the due
> date).
> 
> I think this should be a good solution.
> 
> Just trialing it locally first.

Hi David! This is how we would like it to work too. (We = Lund university :) )

We'd be happy to test your patch when you think it's ready!
Comment 8 Ray Delahunty 2019-03-19 14:39:27 UTC
Almost 3 years after going live with auto-renewals, including our workaround to deal with bug 19014 we have this very day found that the RenewalPeriodBase was set wrongly (left set the "current date", which was sensible for a manual renewal environment, but is I think NOT sensible for an auto-renewal one). This variable has had an impact on renewal timings and renewal outcomes. Our calendar has Sa/Su as closed days, items being 7 day loans, the No Renewal Before set to 1, and  auto-renewal running at 10pm Mo-Su. These variables coupled with the wrong RenewalBasePeriod has seen the loan period on renewal drop a day, until the Monday is reached and then the Sunday closure is seen and items renew every Monday for 7 days from then on. So many variables interact with auto-renewal functionality it is challenging to get then all "right". We are about to look at 18.11 to see how many bug fixes have made it there, up from our 17.05 version (especially bug 19014). But if unexpected timing puzzles are happening, it might be worthwhile checking the RenewalBasePeriod setting to see if it is set correctly.
Comment 9 David Cook 2019-03-25 03:50:41 UTC
Letting folks know that I have a patch for this issue at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014
Comment 10 Andrew Fuerste-Henry 2019-12-31 15:14:24 UTC

*** This bug has been marked as a duplicate of bug 19014 ***