Bug 25096 - Patrons who have opted out of auto-renew should not be subject to No Renewal Before
Summary: Patrons who have opted out of auto-renew should not be subject to No Renewal ...
Status: RESOLVED MOVED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-09 12:55 UTC by Andrew Fuerste-Henry
Modified: 2020-05-06 17:56 UTC (History)
6 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 2020-04-09 12:55:30 UTC
Bug 24476 adds the ability to opt out of auto-renewal. Auto-renewal is generally set up to use a No Renewal Before value. If a patron opts out of auto-renewal, their manual renewals are still subject to that No Renewal Before value.

To recreate:
- set a circ rule that uses auto-renew and sets a No Renewal Before value of 1.
- find a patron and item subject to that circ rule
- set the patron to opt out of auto-renewal
- check the item out to the patron, making sure the due date is more than 1 day in the future
- observe that while the checkout will not auto-renew, it cannot be manually renewed yet
Comment 1 Katrin Fischer 2020-04-12 14:53:41 UTC
Hi Andrew, sorry, but I got to disagree :)

Iirc filed the original bug for 'no renewal before' and it was added, before the auto-renew was added to Koha.

The reasoning is the calculation of new due dates on renewal:

If you want to calculate the new due date on the base of the old due date, there was nothing to prevent users going into the OPAC after checking out an item and immediately renew the item x times to extend the loan period to the max without holds forcing them to return the items.

If you calculate the new due date on today's date, this would be prevented, but also users might be surprised that the due date only gets extended a few days or not at all (when renewing the same day). 

So the no renewal before allows to avoid these problems. We are using it with a lot of libraries that are not using auto-renewals.
Comment 2 Katrin Fischer 2020-04-12 15:02:51 UTC
Found the original bug:
Bug 7413 - Allow OPAC renewal x days before due date

Actually the developer is also the initial auto-renew developer (I had forgotten that! ) - but while it was thought to be helpful with auto-renewals later on, the original idea was not linked to it and it has different use cases.
Comment 3 Andrew Fuerste-Henry 2020-04-13 12:04:09 UTC
Fair enough! I don't know that I've worked with a library using No Renewal Before without auto-renew, so I tend to forget it's an option. In that case, I think the path forward is the more complicated prospect of maintaining separate rules for No Renewal Before for manual and automatic renewal.
Comment 4 Katrin Fischer 2020-04-13 12:08:05 UTC
(In reply to Andrew Fuerste-Henry from comment #3)
> Fair enough! I don't know that I've worked with a library using No Renewal
> Before without auto-renew, so I tend to forget it's an option. In that case,
> I think the path forward is the more complicated prospect of maintaining
> separate rules for No Renewal Before for manual and automatic renewal.

I think you might be right - especially since you can opt out/opt in now individually. It's nice, but it complicates things.
Comment 5 Andrew Fuerste-Henry 2020-04-13 12:21:51 UTC
Noting in case folks end up here after running into this, if you leave No Renewal Before blank it will function as a zero for auto-renewal (meaning no renewal before due date) but have no effect on manual renewal.
Comment 6 Andrew Fuerste-Henry 2020-05-06 16:17:47 UTC
Filed bug 25393 suggesting the creation of a No Automatic Renewal Before rule.