renewal fails in opac when user has reached max items out

Bug #822918 reported by Shae
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
2.0
Fix Released
Undecided
Unassigned

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.

Tags: pullrequest
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git

Revision history for this message
Doug Kyle (dkyle) wrote :

Patch against master attached

Revision history for this message
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.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;
h=77d5f88e9ca5419b063b18ee424b4531cf1fe034

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
Revision history for this message
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
Revision history for this message
Jason Etheridge (phasefx) wrote :

Here's a version for 2.0: collab/phasefx/renewal_checkout_counting_rel_2_0 @ working/Evergreen.git

http://git.evergreen-ils.org/?p=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.

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.