Bug 22018 - Add an option to 'AllowEarlyRenewal' to enable users to renew before the autorenew date
Summary: Add an option to 'AllowEarlyRenewal' to enable users to renew before the auto...
Status: RESOLVED DUPLICATE of bug 25393
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement with 11 votes (vote)
Assignee: Tomás Cohen Arazi
QA Contact: Testopia
URL:
Keywords:
: 21498 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-12-18 11:41 UTC by Martin Renvoize
Modified: 2023-12-08 12:31 UTC (History)
17 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 Martin Renvoize 2018-12-18 11:41:30 UTC
There are occasions where a patron may want to manually renew an item before the date on which an autorenewal would take place; for example, if they are going on holiday they may wish to renew all their items before they leave to prevent them accruing fines whilst away.  Autorenewals can be blocked by a hold having been placed on an item, and if this hold was placed after the original patron had left for their holiday but before the autorenewal date then the patron has no option but to start accruing a fine.
Comment 1 Katrin Fischer 2018-12-18 11:54:03 UTC
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
Comment 2 AspenCat Team 2019-02-08 05:41:17 UTC
This would also allow staff to renew as even staff cannot override the autorenew to renew early
Comment 3 Andrew Fuerste-Henry 2019-12-31 15:15:59 UTC
Most libraries I help with auto-renew are concerned about their patrons' inability to manually renew early, so I agree this would be a good feature. I do like Katrin's proposal of "no renewal before" and "no auto-renewal before."
Comment 4 David Cook 2020-07-09 05:02:49 UTC
I agree that patrons need to be able to manually renew items even when autorenewals is turned on.
Comment 5 Andrew Isherwood 2021-02-04 17:16:06 UTC
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.
Comment 6 Andrew Isherwood 2021-02-05 10:59:27 UTC
I've been doing some more thinking about this and I'm not understanding the relevance of norenewalbefore, as mentioned by Katrin.

It seems that the requirement is to allow manual renewals when autorenewals are enabled. True, norenewalbefore could prevent the user manually renewing, but so could a number of other factors, it seems like those are outside of the scope of this bug.

I have also come up with an example scenario where allowing manual renewals would prevent the user incurring a huge fine (excuse the UK format dates):

28 day loan period - Current situation
--------------------------------------
- Item loaned 01/01 - due 29/01
- norenewalbefore set to 7 days, so cannot renew before 22/01
- Patron going away 18/01 - 18/02
- Hold is placed on 19/01 so autorenewal on 29/01 doesn't happen
- Patron incurs fines from 30/01 -> 19/02, when they return the item

Following development
---------------------
- Patron renews item on 17/01 just before they go away, new due date 14/02
- Hold is placed on 19/01 so autorenewal on 14/02 doesn't happen
- Patron incurs fines from 15/02 -> 19/02, when they return the item

Katrin, could you elaborate on why you brought up norenewalbefore? I don't want to miss some subtlety before I begin work on this :-)
Comment 7 Katrin Fischer 2021-02-06 16:48:28 UTC
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 :)
Comment 8 Katrin Fischer 2021-02-06 17:08:36 UTC
I realize this all might change a bit with 

- RenewalPeriodBase is set to 'current date'.

The issue we had there was that the patrons would renew early and get surprised by a short (or no) extension of the loan period. I guess displaying a hint would have been an option "this will only extend your due date by ... days". So we are basically always using the 'due date' option here.
Comment 9 Andrew Isherwood 2021-02-08 12:56:54 UTC
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!
Comment 10 Andrew Fuerste-Henry 2021-06-22 18:27:41 UTC
*** Bug 21498 has been marked as a duplicate of this bug. ***
Comment 11 Emily Lamancusa 2022-10-26 18:13:41 UTC
It seems to me like a good solution may be to make this a syspref, so that libraries can make their own decisions about how they want to prioritize between giving patrons more flexibility to manually renew vs. preventing people from gaming the system. I think it would work well with Katrin's idea of splitting the restriction into 'no auto-renewal before' and 'no manual renewal before', so that libraries could have a syspref for each to customize for their use case.
Comment 12 Pedro Amorim 2023-09-01 09:24:58 UTC
This requirement should be satisfied by bug 25393 with norenewalbefore circ rule having a higher value than the new noautorenewalbefore circ rule added in that bug.

Bug 25393 allows the patron to place a manual renewal handled by the norenewalbefore rule, while at the same time the auto renewals are handled by the noautorenewalbefore rule, effectively enabling users to renew before the autorenew date.
Comment 13 Nick Clemens 2023-12-08 12:31:30 UTC

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