https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Limit auto-renewal notice |Patrons should not get a |to item due immediately. |on_reserve notification if |Template Toolkit change? |the checkout is due in the | |future CC| |jonathan.druart@bugs.koha-c | |ommunity.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 65590 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=65590&action=edit Bug 19014: Do not sent on_reserve notification if the checkout is due in the future If holds exist on an item that have been checked out and marked as auto renewal, we do not want to notify patrons with a on_reserve notification if the checkout is due in the future. These on_reserve notifications must only be sent if the checkout is due today or in the past. Test plan: - Check an item in and mark it as auto renewal, use a due date in the past to ease the testing - Place a hold in this item - Execute the cronjob => Without this patch, the patron will get notified even if the checkout is due in the future => With this patch applied the patron will only get notified the day the checkout is due or if the due date is passed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=19053 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |15705 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15705 [Bug 15705] Notify the user on auto renewing -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It seems a bit harsh to send the notice the day the item is due, as this means the patron will only have 'that day' to return the book safely. But as the automatic renewal will be tried daily depending on 'No renewal before' and (I tihnk) 'No automatic renewal after' I am not sure how to avoid spamming the patrons with lots of emails. I guess ideally one email would be sent the first time the renewal fails? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com Status|Needs Signoff |Failed QA --- Comment #5 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Hi Jonathan, I'm having trouble testing this. Which cron job are we supposed to run? Is it automatic_renewals.pl --send-notices? Furthermore, I had an item due in the future (in december) and I still received a notice saying the auto renewal failed because I had fines (which was true). But why would it try to renew something due in december? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20360 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com --- Comment #7 from Nick Clemens <nick@bywatersolutions.com> --- We have several libraries with different opinions on this: Some want the emails to be sent the day the item becomes non-renewable Some want the notices sent on the day the item would be renewed This patch seems to send the notice on the due date of the item Could this be done as a switch in the cronjob? (or a syspref?) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I am not sure all libraries can generally agree to send the notice on date due, because then the user has no way to return the item on time usually. I think there are separate issues thinking about the notice: - Don't send a notice every day the item is not returned, sent a notice once or at least not too often - Be able to inform the patrons on time before the due date so they are able to return the item on time - Don't inform the user weeks ahead Could it help to set the "No renewal before" to a lower number of days? This would prevent auto renewals from happening and together with "No automatic renewal after" could limit the timeframe for sending the notice to a few days. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Niamh <niamh.walker-headon@it-tallaght.ie> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |niamh.walker-headon@it-tall | |aght.ie -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #10 from Ray Delahunty <r.delahunty@arts.ac.uk> --- We have a test system at 17.11.04 and are investigating whether this problem / dilemma can be solved with the code, which I understand will solve the problem in this bug and the one in 20360 (and which is a candidate for 18.05) can possibly be added to our 17.11 version. We have a workaround where we disabled AUTO_RENEWALS notices and use ODUE to notify of auto-renewal failure, and RENEWALS to notify of auto-renewal success. We are today undoing this workaround and if the code can work in 17.11 we plan to address Katrin’s concerns expressed above by a mix of changes to ‘No renewal after’, ‘No renewal before’, choice of time for the auto-renewal job to run, and generous use of a grace period. These Circulation & Fine Rules changes do not solve every problem, but if they work, they will offer some improvement. If the code does not work, I think we may have to reinstate the workaround, and wait for Koha 18.05. Test plan. We set ‘No automatic renewal before’ to 2 days. We set ‘No automatic renewal after’ to 1 day. We set the time of the auto-renewal job to 7am. We set the RenewalBasePeriod to “old due date”. We set the Grace Period to 3 days. Assuming the new code solves both this bug and the one in 20360, this is what we would expect: Situation 1. Item is reserved / on hold and due date on Thursday. Auto-renewal job runs at 7am Wednesday, and AUTO_RENEWAL notice is sent advising of renewal failure. User has two remaining loan days and the three grace period days before fines start. If the reservation / hold is cancelled after the job has run or is fulfilled by another copy after 7am on Wednesday but before 7am Thursday, the second run of the auto-renewal job will result in the item being renewed, with the new date based on the old date (so the early renewal does not affect the loan period). Situation 2. Item is not reserved / on hold or otherwise blocked from renewal (say, due to max renewals count being reached) and it is due on Thursday. Auto-renewal job runs at 7am Wednesday, and AUTO_RENEWAL notice is sent advising of renewal success, with the new due date based on the old date. The early renewal does not badly affect the current holder- other than appearing to be an ‘early renewal’. But it does mean that if someone else places a reservation / hold on the title on the Wednesday or Thursday they will have a long wait than if the renewal were close to the original due date. We can play about with the settings in Circulation & Fine Rules to get the “best possible outcome” of minimal affect for maximum users (maybe set the ‘No Auto renewal before’ back to 3 days?) but whatever we do, it won’t be perfect as there are potentially problems with whatever settings we choose. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Michal Denar <black23@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |black23@gmail.com --- Comment #12 from Michal Denar <black23@gmail.com> --- Hi, any progress with this issue? Thank you. Mike -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #14 from David Cook <dcook@prosentient.com.au> --- I've run into this same problem, but my thinking was that C4::Circulation::CanBookBeRenewed() should check for "too_soon" before "on_reserve". In fact, shouldn't reserves be the last thing checked when determining whether or not a book can be renewed? Here's the scenario I see: 1. Patron A autorenews Book A on Wednesday morning 2. Patron B reserves Book A on Wednesday afternoon 3. Patron A receives autorenewal failure for Book A on Thursday morning Here's some SQL I've used to find instances of that scenario happening (the search strings will depend on the content of your notices): select m.borrowernumber, m.message_id, mq.message_id, m.time_queued, mq.time_queued,m.content, mq.content from message_queue m join message_queue mq ON m.borrowernumber = mq.borrowernumber AND substring(m.content,locate('The following item',m.content),30) = substring(mq.content,locate('The following item',mq.content),30) AND date(date_add(m.time_queued, INTERVAL 1 DAY)) = date(mq.time_queued) where m.letter_code = 'AUTO_RENEWALS' and mq.content like '%item is on hold%' ORDER BY m.borrowernumber -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #15)

I think the proper solution might be to refactor C4::Circulation::CanBookBeRenewed and then maybe make a separate function C4::Circulation::CanBookBeAutoRenewed and make that configurable, since it seems that different libraries have different needs/wants for autorenewal.

That said, I don't have the resources to do this at present. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Daniel Gaghan <daniel.gaghan@pueblolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.gaghan@pueblolibrary | |.org --- Comment #18 from Daniel Gaghan <daniel.gaghan@pueblolibrary.org> --- Having read over the comments here, there's nothing I can add besides saying that Pueblo City County Library District is hoping for a fix for this in 2019. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- In 2019, I'm still having librarians getting in touch over irate patrons getting misleading notifications. And now it's not just holds. It's also notifications about reaching the limit of renewals, even though they won't need to autorenew for another 3 weeks. It seems like most people aren't affected by the problems with how autornewals works because they don't have notices set up, but the people who do get notices are plagued by notices that don't make sense. I think it's clear that we need to do "something". But how do we reconcile the people who like the current functionality and the people who hate the current functionality? Looking at Jonathan's patch, it doesn't go far enough. Maybe the easiest thing to do is refactor CanBookBeRenewed to have the "auto_too_soon" code put into a function... and then add that function wrapped in a system preference in automatic_renewals.pl, so that people can toggle between the preferred behaviours. I don't like it... I think everyone should agree with me about what I think is logical (hahahaha), but that might be the most feasible path forward. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 AspenCat Team <aspencatteam@clicweb.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aspencatteam@clicweb.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=22333 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #21 from Ray Delahunty <r.delahunty@arts.ac.uk> --- Almost 3 years after going live with auto-renewals, including our workaround to deal with this bug 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. But if unexpected timing puzzles are happening, it might be worthwhile checking the RenewalBasePeriod setting to see if it is set correctly. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #23 from David Cook <dcook@prosentient.com.au> --- (In reply to Liz Rea from comment #22)

I'd like to test what's here, but don't want to waste the time if it's just going to be superceded. If no one is going to submit a counterpatch in the very near term, this looks like it will be an improvement and the patch probably needs attention so as not to waste Jonathan's work.

For the record, it still applies and I plan to test it in the very near term, unless someone says "no here is my go at fixing this."

Liz

Thanks, Liz. I do have a counterpatch which I've been using locally for one client... I'll post it here. It's actually not too dissimilar from Jonathan's patch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #25 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #24)

Created attachment 86960 [details] [review] [Alternate patch] Bug 19014: Do not try to autorenew an item too early

I think this emulates the behaviour of other current LMSes/LSPs that use automatic renewal, and is what patrons would expect. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Joy Nelson <joy@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joy@bywatersolutions.com --- Comment #27 from Joy Nelson <joy@bywatersolutions.com> --- It seems logical that the autorenewal process should only be looking at issues at the time specified for autorenewal. i.e. Only try to renew items on the 'No renewals before" duedate value. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #29 from David Cook <dcook@prosentient.com.au> --- (In reply to Joy Nelson from comment #27)

It seems logical that the autorenewal process should only be looking at issues at the time specified for autorenewal. i.e. Only try to renew items on the 'No renewals before" duedate value.

I agree. I think it's both logical and it seems to be the way that other library systems do it as well, which suggests to me that is what patrons would expect as well. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #31 from Björn Nylén <bjorn.nylen@ub.lu.se> ---

From our perspective Davids patch is the logical way it should function. Don't do anything until it's time to renew.

However it does change the behaviour and I guess some libraries might like to keep sending early notices if no further renewal will be possible. Perhaps it's possible to control it with a command line option (eg '--early-notice') to skip the no-renwal-before check?(with the risk of asking for a more complex solution) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Jess Tobin <lara005@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lara005@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #34 from David Cook <dcook@prosentient.com.au> --- (In reply to Ray Delahunty from comment #32)

(In reply to Andrew from comment #26)

Are we focussing too much on manipulating when the auto-renewal takes place as being the driver of limiting how many people receive renewal-failure emails? I think we need a better driver. Auto-renewing an item earlier than the moment it is due back penalises other users who may want the item.

No it doesn't. Other users can place a hold on the item.

If it has already auto-renewed (early) and they place a reservation / hold on it, they will have to wait longer for it.

The same thing could be achieved by a person manually renewing it. I don't see how this is relevant?

That is why we have opted for the (admittedly harsh) situation where we only warn users that items have failed auto-renewal when they are overdue. (We use a No Renewal Before value set to zero, but we do use a long grace period.)

I think this is what most people do with Koha at the moment.

We have multiple copies of the same item (with various loan periods) out on loan. If a reservation is placed we want to send renewal-failure notification only to users whose copy is due “soon”, and not to people who have, say, just taken a long-term loan copy out. Native Koha auto-renewal functionality currently sees every holder of the item emailed. But the first copy returned satisfies the reservation. Why pester everyone- we want to better target the email.

Fair enough although I think that's a separate issue to this one.

In comment 26 Andrew mentions what I think could be the ideal solution- a No Notice Before parameter. Rather than this being a system preference I see it better as an additional column in the Circulation & Fine rules. This would be configurable line by line (user category / item type) and allow the Koha library to email as many or as few current holders of the non-renewed items as they wished. Libraries that wanted to be more lenient that us could increase the No Renewal Before to 1, 2, or 3, say, but it would be the wise choice of a No Notice Before value that would be the best driver in targeting users whose items are likely to fulfil the reservation / hold.

I'm not interested in this idea, but you are free to pursue that idea by yourself or pay someone else to pursue it. I've provided my alternate patch as it's how me and my clients think the auto-renewal should work, and we've already implemented it locally and are satisfied with that. I've uploaded it here as I think other people would benefit from it as well. That's the limit to my contribution on this particular bug report though. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Cori Lynn Arnold <carnold@dgiinc.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carnold@dgiinc.com --- Comment #35 from Cori Lynn Arnold <carnold@dgiinc.com> --- So, I was asked nicely to wade in on this as a librarian. I think that: 1. Koha should not notify patrons that a book is eligible to be renewed in the _way_ far future, as the original text says. 2. There should be a configurable time (lets say 3 days for the sake of argument) where patrons are notified that material: a. Has been auto-renewed and the new due date is YYYYMMDD b. Cannot be auto-renewed and must be returned on date XX-XX-XX -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #37 from Nick Clemens <nick@bywatersolutions.com> --- I tested David's patch with our educators, I don't think it quite does what it meant to do. I attached an updated version of David's patch that simplifies the logic, I believe this fulfills the intent -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #39 from Andrew <andrew@bywatersolutions.com> --- Hi David! Nick could give you better details, but we got stuck at one point in your test plan when, with the patch applied, the system wouldn't renew or apply an auto-renew error to a checkout that was within the window defined by No Renewal Before but was not yet overdue. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|17509 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17509 [Bug 17509] Notify patrons to return items requested on hold by another person -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #65590|0 |1 is obsolete| | Attachment #86960|0 |1 is obsolete| | Attachment #90509|0 |1 is obsolete| | --- Comment #42 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 95348 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95348&action=edit Bug 19014: Only process issues for autorenewal if on or after soonest renewal date This patch check the soonest renewal date and skips processing auto renewals if before this date This ensures patrons won't get notifications far in advance if an item is on hold or has other issues To test: 1 - Checkout an item to a patron with a due date 2 days in the future and 'No renewal before' unset 2 - Place a hold on that item 3 - Define an AUTO_RENEWALS circulation notice with below at a minimum [% checkout.auto_renew_error %] 4 - perl misc/cronjobs/automatic_renewals.pl --send-notices 5 - Patron is not notified 6 - Set 'No renewal before' to 1 7 - run cronjob 8 - Patron is notified with error 'on_reserve' 9 - Set 'No renewal before' to 3 10 - UPDATE issues SET auto_renew_error = NULL; 11 - run cronjob 12 - Patron is notified with error 'on_reserve' 13 - APPLY PATCH 14 - Unset 'No renewal before' 15 - UPDATE issues SET auto_renew_error = NULL; 16 - run cronjob 17 - Patron is not notified 18 - UPDATE issues SET auto_renew_error = NULL; 19 - Set 'No renewal before' to 1 20 - run cronjob 21 - Patron is notified with error 'on_reserve' 22 - Set 'No renewal before' to 3 23 - UPDATE issues SET auto_renew_error = NULL; 24 - run cronjob 25 - Patron is not notified -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_20_05_target -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #43 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- New test plan: To test: 1 - Checkout an item to a patron with a due date 2 days in the future and 'No renewal before' set to 1 2 - Place a hold on that item 3 - Define an AUTO_RENEWALS circulation notice with below at a minimum [% checkout.auto_renew_error %] 4 - Patron is notified with error 'on_reserve' 5 - Set 'No renewal before' to 3 6 - UPDATE issues SET auto_renew_error = NULL; 7 - run cronjob 8 - Patron is notified with error 'on_reserve' 9 - APPLY PATCH 10 - Set 'No renewal before' to 1 11 - UPDATE issues SET auto_renew_error = NULL; 12 - run cronjob 13 - Patron is not notified 14 - UPDATE issues SET auto_renew_error = NULL; 15 - Set 'No renewal before' to 3 16 - UPDATE issues SET auto_renew_error = NULL; 17 - run cronjob 18 - Patron is notified with error 'on_reserve' -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #45 from Nick Clemens <nick@bywatersolutions.com> --- Please retest -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 ByWater Sandboxes <bws.sandboxes@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95851|0 |1 is obsolete| | --- Comment #47 from ByWater Sandboxes <bws.sandboxes@gmail.com> --- Created attachment 95852 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=95852&action=edit Bug 19014: Only process issues for autorenewal if on or after soonest renewal date This patch check the soonest renewal date and skips processing auto renewals if before this date This ensures patrons won't get notifications far in advance if an item is on hold or has other issues To test: 1 - Checkout an item to a patron with a due date 2 days in the future and 'No renewal before' unset 2 - Place a hold on that item 3 - Define an AUTO_RENEWALS circulation notice with below at a minimum [% checkout.auto_renew_error %] 4 - perl misc/cronjobs/automatic_renewals.pl --send-notices 5 - Patron is not notified 6 - Set 'No renewal before' to 1 7 - run cronjob 8 - Patron is notified with error 'on_reserve' 9 - Set 'No renewal before' to 3 10 - UPDATE issues SET auto_renew_error = NULL; 11 - run cronjob 12 - Patron is notified with error 'on_reserve' 13 - APPLY PATCH 14 - Unset 'No renewal before' 15 - UPDATE issues SET auto_renew_error = NULL; 16 - run cronjob 17 - Patron is not notified 18 - UPDATE issues SET auto_renew_error = NULL; 19 - Set 'No renewal before' to 1 20 - run cronjob 21 - Patron is notified with error 'on_reserve' 22 - Set 'No renewal before' to 3 23 - UPDATE issues SET auto_renew_error = NULL; 24 - run cronjob 25 - Patron is not notified Signed-off-by: Signed-off-by: Signed-off-by: Hasina Akhter <hasinaa@pascolibraries.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #49 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- It would be nice if some of the people involved earlier could add a comment on the last signed off patch. It is actually the third try to solve this, if I am reading well. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #51 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Nick, do not we want to truncate to days before the date comparison? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95852|0 |1 is obsolete| | --- Comment #52 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 96688 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=96688&action=edit Bug 19014: Unit tests -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #54 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #51)

Nick, do not we want to truncate to days before the date comparison?

Yes, we already have this code in C4::Circulation:CanBookBeRenewed - I submit a new patch to make use of that code and cover it with tests rather than add logic to the cron -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #56 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Stalling out on signing this off while holds are broken, but reading your test plan for the 100th time. In steps 19-21 we have an item due in 2 days and no renewal before set to 1 day. If our goal is to not send a notice outside of the no renewal before period, shouldn't our patrons *not* get a notice in this situation? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #57 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- With this patch applied renewal is not blocked by a hold. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #58 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 97374 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=97374&action=edit Bug 19014: on_reserve blocks auto_renew -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 ByWater Sandboxes <bws.sandboxes@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #96689|0 |1 is obsolete| | --- Comment #60 from ByWater Sandboxes <bws.sandboxes@gmail.com> --- Created attachment 97396 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=97396&action=edit Bug 19014: Return auto_too_soon before on_reserve When calling CanBookBeRenewed we do check for 'too_soon', however, a reserve makes the return 'on_reserve' before other statuses. It seems the patron specific reasons should be returned first. This patch places the 'on_reserve' check after too_soon and others To test: 1 - Checkout an item to a patron with a due date 2 days in the future and 'No renewal before' unset 2 - Place a hold on that item 3 - Define an AUTO_RENEWALS circulation notice with below at a minimum [% checkout.auto_renew_error %] 4 - perl misc/cronjobs/automatic_renewals.pl --send-notices 5 - Patron is not notified 6 - Set 'No renewal before' to 1 7 - run cronjob 8 - Patron is notified with error 'on_reserve' 9 - Set 'No renewal before' to 3 10 - UPDATE issues SET auto_renew_error = NULL; 11 - run cronjob 12 - Patron is notified with error 'on_reserve' 13 - APPLY PATCH 14 - Unset 'No renewal before' 15 - UPDATE issues SET auto_renew_error = NULL; 16 - run cronjob 17 - Patron is not notified 18 - UPDATE issues SET auto_renew_error = NULL; 19 - Set 'No renewal before' to 1 20 - run cronjob 21 - Patron is notified with error 'on_reserve' 22 - Set 'No renewal before' to 3 23 - UPDATE issues SET auto_renew_error = NULL; 24 - run cronjob 25 - Patron is not notified Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #62 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Modified test plan: 1 - Checkout an item to a patron with a due date 2 days in the future and 'No renewal before' unset 2 - Place a hold on that item 3 - Define an AUTO_RENEWALS circulation notice with below at a minimum [% checkout.auto_renew_error %] 4 - perl misc/cronjobs/automatic_renewals.pl --send-notices 5 - Patron is not notified 6 - Set 'No renewal before' to 1 7 - run cronjob 8 - Patron is notified with error 'on_reserve' 9 - Set 'No renewal before' to 3 10 - UPDATE issues SET auto_renew_error = NULL; 11 - run cronjob 12 - Patron is notified with error 'on_reserve' 13 - APPLY PATCH 14 - Unset 'No renewal before' 15 - UPDATE issues SET auto_renew_error = NULL; 16 - run cronjob 17 - Patron is not notified 18 - UPDATE issues SET auto_renew_error = NULL; 19 - Set 'No renewal before' to 2 20 - run cronjob 21 - Patron is notified with error 'on_reserve' 22 - Set 'No renewal before' to 3 23 - UPDATE issues SET auto_renew_error = NULL; 24 - run cronjob 25 - Patron is notified with error 'on_reserve' -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #97395|0 |1 is obsolete| | --- Comment #64 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 98704 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98704&action=edit Bug 19014: Unit tests Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #97397|0 |1 is obsolete| | --- Comment #66 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 98706 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98706&action=edit Bug 19014: on_reserve blocks auto_renew -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #98705|0 |1 is obsolete| | --- Comment #68 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 98718 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98718&action=edit Bug 19014: Return auto_too_soon before on_reserve Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #70 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 98720 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98720&action=edit Bug 19014: (QA follow-up) Update test for AddReserve change Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |20.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_05_target, | |RM_priority | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #74 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 100180 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100180&action=edit Bug 19014: [19.11.x] Prevent auto_renew notices form sending if too early to renew Bug 19014: Unit tests Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Bug 19014: Return auto_too_soon before on_reserve Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Bug 19014: on_reserve blocks auto_renew Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com --- Comment #76 from Lucas Gass <lucas@bywatersolutions.com> --- Doesn't apply cleanly to 19.05.x branch. No backport -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@koha-us.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 --- Comment #78 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I've played with this a bit more now and am inclined to agree with Jonathan regarding reverting this from stables and waiting for the enhancement to surface with the 20.11 release with the followup bug hopefully resolving the issues this introduced. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|bugzilla@koha-us.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |These patches alter the release notes| |behaviour of | |'CanBookBerenewed' to | |return a status of | |'too_soon' before any other | |statuses if the book is not | |eligible for renewal yet. | |This is done to prevent | |sending messages to patrons | |about other changes in | |status when it is still too | |soon to renew the item -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=34924 -- You are receiving this mail because: You are watching all bug changes.