Bug 26209

Summary: BlockReturnofLostItems does not prevent lost items being found
Product: Koha Reporter: Martin Renvoize <martin.renvoize>
Component: CirculationAssignee: Bugs List <koha-bugs>
Status: CLOSED WORKSFORME QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: andrewfh, fridolin.somers, gmcharlt, katrin.fischer, kyle.m.hall, kyle, martin.renvoize, nick, testopia, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 15751, 21231    
Bug Blocks:    

Description Martin Renvoize 2020-08-14 09:51:34 UTC
+++ 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?
Comment 1 Andrew Fuerste-Henry 2020-08-14 12:03:02 UTC
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.
Comment 2 Katrin Fischer 2020-08-16 07:44:04 UTC
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?
Comment 3 Kyle M Hall 2021-03-22 13:23:30 UTC
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
Comment 4 Andrew Fuerste-Henry 2021-03-22 13:43:10 UTC
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.
Comment 5 Martin Renvoize 2021-03-22 16:14:34 UTC
* '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.