renewal fails in opac when user has reached max items out

Bug #822918 reported by Shae on 2011-08-08
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

At version 2.0.7, it appears that a patron cannot renew any items if they've reached the max # of items out. The patron is not blocked or barred. They are in good standing with no overdues or bills attached to their account. They have 5 DVDs checked out, which is the max # they can have according to circ policies. They have renewals remaining on all 5 DVDs and there are no holds associated with those titles. When trying to renew the item via the opac, an error comes up indicating that the renewal failed and that it may have something to do with holds on the items. This was reported by a customer but has been replicated on an in house 2.0.7 system. Please let me know if you need more details.

Michael Peters (mrpeters) wrote :

We've seen the same behavior here in Indiana with legacy circ scripts and on 2.0.4.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Shae (shae-esilibrary) wrote :

This was on 2.0.7 and they were def using in-db rules so sounds like maybe this has been around longer than I realized and no one reported it. If I can provide any further info or testing, please let me know.

Shae (shae-esilibrary) wrote :

Just an update that I tested this on an in house 2.1 release candidate and it happens there also. Rule was for Kits. The patron could have 2 Kits at a time with a duration rule of 3 days 1 renewal. I checked out 2 kits with this duration rule. When I try to renew via the OPAC, it tells me the system was unable to renew and this generally means there are holds on the items (even though there are no holds on either item). Thank you for checking this out.

Doug Kyle (dkyle) wrote :

I wrapped the code in action.item_user_circ_test that counts items out in a IF NOT renewal THEN block, not sure if that is the best way to deal with this but it seems to be working.

Galen Charlton (gmc) wrote :

Doug: could you provide a git patch against master, or at least against rel_2_0? This would make it easier (and more likely) that your change will be reviewed in a timely fashion. Instructions on preparing a patch can be found on the Evergreen wiki at

Doug Kyle (dkyle) wrote :

Patch against master attached

Michael Peters (mrpeters) wrote :

This one was sitting idle so I pushed this to a branch so we can get this pulled into 2.1's upgrade script.;a=commitdiff;

I attempted to credit Doug as the author, but it still came out saying I authored it. Just want to be sure Doug gets credit. This is a really helpful patch!

tags: added: pullrequest
Changed in evergreen:
status: Confirmed → In Progress
milestone: none → 2.1.0
Mike Rylander (mrylander) wrote :

Reworked from Doug's original patch for master and 2.1. Thanks, all!

Changed in evergreen:
status: In Progress → Fix Committed
milestone: 2.1.0 → 2.1.1
Changed in evergreen:
status: Fix Committed → Fix Released
Jason Etheridge (phasefx) wrote :

Here's a version for 2.0: collab/phasefx/renewal_checkout_counting_rel_2_0 @ working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/renewal_checkout_counting_rel_2_0

Not sure how someone should do the numbering for the upgrade version.

Mike Rylander (mrylander) wrote :

Pushed into 2.0 with a placeholder upgrade script forward-ported to master and 2.1 to avoid collisions in the future.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers