https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think maybe it would be better to break up the 'no renewal before' instead and have a 'no auto-renewal before' and 'no other renewal before'. Initially the 'no renewal before' was introduced because depending on your UseDaysMode setting there can be unwanted behavior for normal renewals: - calculate due date from current date = If the patron renews too early, they lose renewals with little gain as the due date will only be extended by a few days or none if they try renewal on the day of checkout - calculate due date from old due date = Patrons can 'play' the system and immediately max out the loan period after checkout -- 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=22018 AspenCat Team <aspencatteam@clicweb.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aspencatteam@clicweb.org --- Comment #2 from AspenCat Team <aspencatteam@clicweb.org> --- This would also allow staff to renew as even staff cannot override the autorenew to renew early -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #4 from David Cook <dcook@prosentient.com.au> --- I agree that patrons need to be able to manually renew items even when autorenewals is turned on. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@collect | |o.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Andrew Isherwood <andrew.isherwood@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.isherwood@ptfs-europ | |e.com --- Comment #5 from Andrew Isherwood <andrew.isherwood@ptfs-europe.com> --- I've been getting my head around the requirement, history and existing code here. My understanding might be flawed, so please don't judge me. We have a syspref called RenewalPeriodBase which makes it possible to specify, when an item is renewed, whether the new due date should be based on either the current date or the item's original due date. In Bug 7413, Katrin pointed out that the second option could be abused to "game" the system to maximise the loan period. Thus, norenewalbefore was born as a mitigation against this by preventing patrons renewing an item more than a specified time period before the item's due date. However, this bug is highlighting that norenewalbefore prevents patrons from pre-emptively renewing an item before going away for a period of time, in order to avoid an autorenewal which would occur while they're away being blocked by a hold being placed on the item. I've had several attempts at sketching out an arrangement of loan periods, autorenewal dates, patron being away dates and norenewalbefore settings that results in the patron getting more than maybe a day's fine, but I've failed to find one. I've tried both long and short loan periods, but cannot find a situation where it is problematic. Could someone describe a scenario where a patron being able to pre-emptively renew an item outside a norenewalbefore period would help them prevent fines? Katrin - I'm not sure what you're getting at with splitting norenewalbefore, could you elaborate on how it will help? Also, isn't any arrangement which allows a user to renew an item pre-emptively going to return us to the original situation of allowing them to "game" the system? Sorry, I'm sure I'm just misunderstanding, so please bear with me. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I am trying Andrew, but I am not sure either :) I'll try with some examples too: 1) Library without auto-renewals and without norenewalbefore limit - RenewalPeriodBase is set to 'date_due' - renewals allowed > 0 - norenewalbefore is not set Patrons would be allowed to renew immediately after checkout to a much longer loan period than intended. This will take away the chance for other users to get the items earlier by placing a hold. 2) Library without auto-renewals - RenewalPeriodBase is set to 'date_due' - renewals allowed > 0 - norenewalbefore is set to x days before Patrons and staff can only renew once the items get close to the due date. Note: if the 'override' renewal doesn't work here yet, it could be nice to have a way to do that for staff. 3) Library with auto-renewals and without norenewalbefore limit - RenewalPeriodBase is set to 'date_due' - renewals allowed > 0 - norenewalbefore is not set This used to mean: That the system would "game" itself. The items would be renewed immediately the first day after checkout. So norenewalbefore determined the first day it should try to renew. The idea here was to try the auto-renew a few days before the actual date due, so in case of it failing, the patron would receive the item due notice and have a change to return the item on time before accumulating fines. -- After the initial introduction of these features a lot more options were added to the auto-renew process. The separate notice was added and Bug 19014 was pushed - I am not sure how that might have changed things. :( It's something you might have a better idea about. So my initial comments were referring to the fact, that maybe we would want to have different settings for manual vs. automatic renewals. I am not stuck to this idea. I believe the use case described by Martin is a bit difficult... if the intention of using auto renewals and holds (instead of just having looong loan periods) is that holds should have the effect of people having to return items, renewing "early" seems like going against that? I feel a bit like you can't have both, but I might lack imagination right now :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Andrew Isherwood <andrew.isherwood@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|martin.renvoize@ptfs-europe |andrew.isherwood@ptfs-europ |.com |e.com --- Comment #9 from Andrew Isherwood <andrew.isherwood@ptfs-europe.com> --- Hi Katrin Thanks for your thoughts, very useful, it's interesting to have some of the historical context.

... if the intention of using auto renewals and holds (instead of just having looong loan periods) is that holds should have the effect of people having to return items, renewing "early" seems like going against that? I feel a bit like you can't have both ...

I think the idea is that it gives the ability for the patron to not have to return an item due to a hold when they are physically unable to do so due to being away. A (probably) naïve approach would be just for us to add a syspref that, if enabled, ignores the "norenewalbefore" restriction checks in C4::CanBookBeRenewed. I notice that in Bug 25758 Nick has added flag that is passed to C4::CanBookBeRenewed indicating if it is being called from the autorenew cron script, so that would negate the need for us to split norenewalbefore into two. However, despite the approach that is taken, I am still unable to see how we can allow patrons to renew items early without re-introducing the ability for them to artificially increase their loan periods when RenewalPeriodBase is set to date_due. Needs more thought I think! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|andrew.isherwood@ptfs-europ |tomascohen@gmail.com |e.com | CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Andrew Isherwood <bugzilla@warmlight.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|bugzilla@warmlight.co.uk | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Daniel B. <dbarden@cuyahogalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dbarden@cuyahogalibrary.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25393 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Nick Clemens <nick@bywatersolutions.com> --- *** This bug has been marked as a duplicate of bug 25393 *** -- You are receiving this mail because: You are watching all bug changes.