[Bug 26209] New: BlockReturnofLostItems does not prevent lost items being found
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 Bug ID: 26209 Summary: BlockReturnofLostItems does not prevent lost items being found Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: andrew@bywatersolutions.com, fridolin.somers@biblibre.com, gmcharlt@gmail.com, katrin.fischer@bsz-bw.de, kyle.m.hall@gmail.com, kyle@bywatersolutions.com, martin.renvoize@ptfs-europe.com, nick@bywatersolutions.com, testopia@bugs.koha-community.org, tomascohen@gmail.com Depends on: 21231 +++ 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? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21231 [Bug 21231] BlockReturnofLostItems does not prevent lost items being found -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 --- Comment #1 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=9805 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |15751 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15751 [Bug 15751] Koha offline circulation Firefox addon does not update last seen date for check-ins -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26209 --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- * '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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org