Applying lost and paid status at the wrong time

Bug #1412893 reported by Ben Shum
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen master / 2.7 series

So, we think we are seeing a situation where the following can occur and have the Lost and Paid status applied to copies prematurely.

An item is checked out, and accrues some overdue fines. The item is renewed, starting a second transaction and the first transaction remains open because the fines have yet to be paid. The second transaction goes to lost, and a lost bill gets applied and the item is marked with a status of Lost. When the library staff go to pay off the first transaction's overdues, and it closed that transaction, it also changes the copy status over to "Lost and Paid."

Looking back at the code, I think that the check for whether to change an item to "lost and paid" occurs every time a transaction closes and it only looks to see if the item is "lost" and the library setting is enabled. So in the situation described above, all those facts are true and the copy is set incorrectly, because actually the 2nd transaction's end by being paid off is what ought to have set the copy status. See changes from:;a=blobdiff;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/;h=040187630f24b95898fb9a2bbd14bb05fc091597;hp=0c1493a351ff8afc1623599bf6f316b1563cf028;hb=64d321c68b2dde3b4e83fdca36c8ccf7acec8aba;hpb=76686de7a0acd689466122a209b38d6db27e86fa

A bit confusing for end users and staff.

Revision history for this message
Michele Morgan (mmorgan) wrote :
  • lp1412893.docx Edit (21.6 KiB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Confirming this bug as I have reproduced it on our training system running 2.7.2.

The attached document shows data for an item that was checked out, reached MAXFINES, then renewed and subsequently marked Lost. The overdue fine on the parent transaction was then paid.

The parent transaction was closed, and the item status flipped to Lost and Paid, even though no portion of the Lost billing was paid.

The item's status should only change to Lost and Paid when the transaction that is being closed has a stop_fines of LOST.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Ben Shum (bshum) wrote :

Thanks for the testing Michele.

I've created the following working branch to attempt resolving this problem by adding an additional check to verify that the stop_fines reason for a given circ is either "LOST" or "LONGOVERDUE" before proceeding with the move to change the item status to "lost and paid".

See: user/bshum/lp1412893_lost_and_paid_fix;a=shortlog;h=refs/heads/user/bshum/lp1412893_lost_and_paid_fix

Special thanks to Jason Stephenson for reviewing my rough perl skills...

Ben Shum (bshum)
tags: added: pullrequest
Changed in evergreen:
milestone: none → 2.7.3
importance: Undecided → Medium
Revision history for this message
Kathy Lussier (klussier) wrote :
tags: added: signedoff
Revision history for this message
Ben Shum (bshum) wrote :

Thanks for testing Kathy, pushed fix to master and rel_2_7.

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments