Item status can be set to Lost and Paid inappropriately when closing a transaction for a Long Overdue or Lost returned item
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Evergreen 2.12 on (likely earlier)
With the library setting to Use Lost and Paid copy status set to True, we have seen the following scenario:
- An item checked out to A. Patron becomes Long Overdue or Lost.
- The item is returned by A. Patron, but the transaction remains open due to a balance owed.
- The item is checked out by B. Patron, and subsequently becomes Long Overdue or Lost.
- The outstanding balance on A. Patron's transaction is paid.
- The item currently checked out to B. Patron now has Lost and Paid status.
This appears to be happening in Money.pm:
500 # If we have a circ, we need to check if the copy
501 # status is lost or long overdue. If it is then we
502 # check org_unit_settings for the copy owning library
503 # and adjust and possibly adjust copy status to lost
504 # and paid.
505 if ($circ && ($circ->stop_fines eq 'LOST' || $circ->stop_fines eq 'LONGOVERDUE')) {
506 # We need the copy to check settings and to possibly
507 # change its status.
508 my $copy = $circ->
509 # Library where we'll check settings.
510 my $check_lib = $copy->circ_lib();
511
512 # check the copy status
513 if (($copy->status() == OILS_COPY_
514 && $U->is_
515 $copy->
516 if (!$e->update_
517 return _recording_failure(
518 $e, "update_
519 $payment, $cc_payload
520 )
521 }
522 }
523 }
The copy could have a status of Lost or Long Overdue as a result of a different circ than the one that's being closed.
Our production system currently has 84 items with Lost and Paid status, but the most recent circ transaction is not closed and has stop_fines of LONGOVERDUE. Spot checking a few of these revealed an older circ (sometimes *much* older) with the same stop_fines and xact_finish that matches the copy's status_
tags: | added: billing |
Changed in evergreen: | |
importance: | Undecided → Medium |
tags: |
added: circ-billing itemstatus removed: billing |
Adding a query to identify likely victims of this bug.
select stop_fines, count(circ.*) from action.circulation circ
join asset.copy ac on ac.id = circ.target_copy
where circ.xact_finish is null
and circ.checkin_time is null
and ac.status in (17)
group by 1
The query reveals an error in my accounting of the 84 items currently erroneously marked Lost and Paid in our production system. 26 of the 84 still open transactions where the copy status has been changed to Lost and Paid have stop_fines LOST.