Bug 26209 - BlockReturnofLostItems does not prevent lost items being found
Summary: BlockReturnofLostItems does not prevent lost items being found
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 15751 21231
Blocks:
  Show dependency treegraph
 
Reported: 2020-08-14 09:51 UTC by Martin Renvoize
Modified: 2021-12-13 21:10 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.