+++ This bug was initially created as a clone of Bug #21231 +++ >When the syspref BlockReturnOfLostItems is set to Block, the item is blocked from being returned, but is still >considered found -- it's set to lost=0 and a refund is applied to the patron (if circ rules allow). The item can >then be checked in a second time and returned as it is no longer lost. There are still a number of logical holes in the code. ModDateLastSeen is called in a number of places without a flag being passed to prevent the itemlost update. I must admit, I find it confusing to be able to update the last seen timestamp when the item is still 'lost'.. it feels like a logical flaw. Should we not alert the user performing the action that the item was lost and get feedback on what to do?
Requesting feedback makes sense to me. My big concern originally was that someone inattentively scanning checkins could just make it found without really realizing it. We could avoid that if we require some sort of more specific interaction to select "Mark this item as found" from an alert.
I like the idea of an alert that requires confirmation (and allows to say "don't mark as found" as well. Maybe the item has already been replaced by the library?
I'm finding the description of this bug to be too vague to be actionable. Can someone provide a test plan that reproduces this bug? Kyle
I am no longer able to recreate this. On masterm, with BlockReturnofLostItems set to Block, I cannot get an item to become un-lost by checking it in.
* 'transferbook' is still a hole, but I'm working on that one by removing transferbook soon. * Calling 'CanBookBeIssue' as a statistical patron 'category X' is a hole.. though I have no idea how one triggers that. * ajax-invetory.pl also calls ModDateLastSeen without passing the lost item pref.. again.. I'm not sure about it. Happy for this to be closed.. it was the transferbook case I think I was most perplexed by.