in-db circ does not consider deposit items

Bug #1065091 reported by Chris Sharp
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

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.

Discuss...

Evergreen 2.1.1
OpenSRF 2.0.1
PG 9.1
Debian squeeze

Revision history for this message
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)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
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
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Jason,

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.

Thanks,

Chris

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Chris,

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,
Jason

Kathy Lussier (klussier)
tags: added: cataloging circ holds
Andrea Neiman (aneiman)
tags: added: circulation
removed: circ
Dan Briem (dbriem)
tags: added: circ-holds
removed: holds
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.