in-db circ does not consider deposit items

Bug #1065091 reported by Chris Sharp on 2012-10-10
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

Our libraries restrict holds on deposit items, which worked well under legacy scripts, but in-db circ policies do not have an attribute to determine whether an item is a deposit/rental item.


Evergreen 2.1.1
OpenSRF 2.0.1
PG 9.1
Debian squeeze

Thomas Berezansky (tsbere) wrote :

My thoughts:

A "min amount" field. Maybe with a check for deposit/rental flag as a second thing.

I will admit that there was discussion of 0 compared to null, though currently there is no "null" allowed.

Ben Shum (bshum) on 2012-12-13
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Jason Stephenson (jstephenson) wrote :

A rental or deposit circ modifier could be used in in-database circulation as is. There isn't a real need to change the code. I'll leave this open but change the importance to wishlist.

Changed in evergreen:
importance: Medium → Wishlist
Chris Sharp (chrissharp123) wrote :


Right - we consider the circ modifier option a less-than-optimal workaround, since we would like the item to retain its current circulation rules. In effect we would need to create multiple circ modifiers for deposit items (e.g. deposit-book, deposit-dvd, etc.) to preserve the previous behavior. Since "deposit" is already a boolean field on all asset.copy objects, shouldn't it be considered?

I'm fine with the wishlist designation. I just wanted to make sure our use case was clear.



Jason Stephenson (jstephenson) wrote :


I think the situation is slightly more complicated than just checking the deposit boolean on the copy. That might work for you, but several of our members use the deposit_amount column without the deposit being on. This latter configuration creates a non-refundable fee charged for the copy, such as $1.00 for a DVD.

Either another field (in addition to deposit) should be added to the matrices to handle this case, or the logic of a new field would need additional states. It could be that this limit would just trigger if deposit_amount were filled in, rather than having the deposit field checked. However, there might be cases where someone would want to differentiate between the two types of fee.

I am not opposed to your request prima facie. I just want to explore the options so that we come up with the best solution for everyone.

Thank you,

Kathy Lussier (klussier) on 2013-04-18
tags: added: cataloging circ holds
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers