Item status can be set to Lost and Paid inappropriately when closing a transaction for a Long Overdue or Lost returned item

[Michele Morgan]

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->target_copy();
 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_STATUS_LOST || $copy->status() == OILS_COPY_STATUS_LONG_OVERDUE)
 514 && $U->is_true($U->ou_ancestor_setting_value($check_lib, 'circ.use_lost_paid_copy_status', $e))) {
 515 $copy->status(OILS_COPY_STATUS_LOST_AND_PAID);
 516 if (!$e->update_asset_copy($copy)) {
 517 return _recording_failure(
 518 $e, "update_asset_copy_failed()",
 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_changed_time.

[Michele Morgan (mmorgan)]

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.

[John Amundson (jamundson)]

I have seen this occur. Our descriptions are very similar.

Patron A checks an item out until it enters Lost status.

Patron A returns the "lost" item, and overdue fines are reinstated.

Some time later, Patron B checks out the item.

The item enters Lost status again.

Patron A pays their overdue fines. Item status is updated to Lost and Paid.