Bug 9805 - Lost items are un-lost if returned, but not if renewed
Summary: Lost items are un-lost if returned, but not if renewed
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Kyle M Hall
QA Contact:
URL:
Keywords:
: 8560 13266 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-13 12:36 UTC by Kyle M Hall
Modified: 2024-02-28 17:54 UTC (History)
27 users (show)

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


Attachments
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.51 KB, patch)
2013-03-13 12:39 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.83 KB, patch)
2013-03-13 13:02 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.88 KB, patch)
2013-03-18 18:24 UTC, Paul Poulain
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Add system preference (4.48 KB, patch)
2014-06-25 11:52 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules (15.01 KB, patch)
2015-03-19 13:17 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.88 KB, patch)
2015-04-23 16:22 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.88 KB, patch)
2015-04-23 16:28 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules (15.12 KB, patch)
2015-04-23 16:28 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.88 KB, patch)
2015-12-04 13:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules (14.07 KB, patch)
2015-12-04 13:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Control renewing and finding of lost items via circ rules (14.07 KB, patch)
2015-12-04 14:00 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (1.88 KB, patch)
2016-01-12 15:40 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Control renewing and finding of lost items via circ rules (14.06 KB, patch)
2016-01-12 15:40 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Fix QA Issue (1.15 KB, patch)
2016-01-12 15:40 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (14.43 KB, patch)
2016-02-03 17:08 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (14.43 KB, patch)
2016-02-03 17:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Update Schema (4.08 KB, patch)
2016-02-03 17:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Unit Tests (4.28 KB, patch)
2016-02-03 17:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (14.41 KB, patch)
2016-03-08 13:01 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Update Schema (4.08 KB, patch)
2016-03-08 13:01 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Unit Tests (4.28 KB, patch)
2016-03-08 13:01 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Lost items are un-lost if returned, but not if renewed. (15.54 KB, patch)
2016-03-14 12:55 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Update Schema (3.09 KB, patch)
2016-03-14 12:56 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 - Unit Tests (4.28 KB, patch)
2016-03-14 12:56 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805 [QA Followup] - Stop calling GetMember repeatedly (4.86 KB, patch)
2016-03-15 11:01 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9805: Lost items are un-lost if returned, but not if renewed. (14.93 KB, patch)
2024-02-27 00:53 UTC, Aleisha Amohia
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2013-03-13 12:36:49 UTC
If an item has a lost status, that status is removed when the item is returned. However, it is not removed if the item is renewed.
Comment 1 Kyle M Hall 2013-03-13 12:39:25 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2013-03-13 13:02:54 UTC Comment hidden (obsolete)
Comment 3 Christophe Croullebois 2013-03-18 13:09:06 UTC
I tested according to the plan test, and on renew with the patch the item become un-lost.
Ok for me.
Comment 4 Paul Poulain 2013-03-18 18:23:32 UTC
QA comment
 * tiny patch, despite it's size
 * passes koha-qa.pl

passed QA
Comment 5 Paul Poulain 2013-03-18 18:24:03 UTC Comment hidden (obsolete)
Comment 6 Katrin Fischer 2013-03-18 22:14:24 UTC
Hm, reading this I wonder - what happens if a patron does a renew all not thinking about the lost book? It will be 'unlost'? I can see why checking in removes the status, because you actually need the book on the circ desk/self check, but for renewing it's not needed so you won't know if it as actually there or not.
Comment 7 Katrin Fischer 2013-03-18 22:15:51 UTC
Hm I missed the status is set by longoverdue.pl so also automatic. Not sure my first comment makes sense now :)
Comment 8 Jared Camins-Esakov 2013-03-20 02:36:30 UTC
I share Katrin's concern. Regardless how the lost status is set, once a book has been marked lost I don't think that all -- or even most -- librarians want the patron to be able to mark it as not lost without presenting the book. I feel like a syspref would be a good idea.
Comment 9 Paul Poulain 2013-03-20 09:13:33 UTC
(In reply to comment #8)
> I share Katrin's concern. Regardless how the lost status is set, once a book
> has been marked lost I don't think that all -- or even most -- librarians
> want the patron to be able to mark it as not lost without presenting the
> book.
Very good point, that I could have think of when QAing !

> I feel like a syspref would be a good idea.
Well, FAUST leader will probably jump in here and say that this syspref could/should be avoided. but I'm not RM anymore, so I just express my concern & let others decide !
Comment 10 Kyle M Hall 2014-06-25 11:37:02 UTC
*** Bug 8560 has been marked as a duplicate of this bug. ***
Comment 11 Kyle M Hall 2014-06-25 11:52:54 UTC Comment hidden (obsolete)
Comment 12 Kyle M Hall 2014-06-25 11:54:15 UTC
Setting to passed qa on the assumption that the system preference was the only blocker for this. Adding system preference has not affected the behavior of the patch. Please set to 'needs signoff' if you feel otherwise.
Comment 13 Tomás Cohen Arazi 2014-07-21 13:48:05 UTC
I personally think that we should re-discuss lost items handling. Will set it as In Discussion, and scheduled it for the next dev meeting. It won't get stalled, just delayed.
Comment 14 Kyle M Hall 2014-07-23 16:03:13 UTC
11:57:12 AM) cait: next one is a discussion on lot item handling
(11:57:27 AM) cait: the bug is bug 9805
(11:57:28 AM) huginn: Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 normal, P5 - low, ---, kyle, In Discussion , Lost items are un-lost if returned, but not if renewed.
(11:58:06 AM) cait: tcohen suggests that we change it to allow/disallow reneal of lost items as an option on the circulation conditions page (not necessarily the big table, but a by branch setting on that page)
(11:58:25 AM) cait: currently it is about resetting the lost satus (finding he item) when you renew
(11:59:18 AM) cait: in my opionion it makes sense to not allow renewal of lost items in the first place, but i am not totally sure how it would impact workflows
(11:59:26 AM) khall: that would be a fine solution by me.
(11:59:46 AM) oleonard: I would think we would need to both allow/disallow renewal of lost item *and* have a preference about whether the status should be removed upon renewal.
(12:00:03 PM) oleonard: However I don't speak based on my library's policy, just in the abstract.
(12:00:08 PM) cait: i am a bit worried if a patron canremove the lost status by renewing in the opac
(12:00:21 PM) cait: that would be confusing about the replacement fee already charged
(12:00:48 PM) barton: good point, cait.
(12:00:57 PM) ColinC: Or if you allow phone renewals ...
(12:01:00 PM) khall: agreed, it's better to block the renewing of lost items altogether
Comment 15 Kyle M Hall 2015-03-18 16:21:56 UTC
*** Bug 13266 has been marked as a duplicate of this bug. ***
Comment 16 Kyle M Hall 2015-03-19 13:17:08 UTC Comment hidden (obsolete)
Comment 17 Nick Clemens (kidclamp) 2015-04-16 21:32:24 UTC
Applying: Bug 9805 - Lost items are un-lost if returned, but not if renewed.
Applying: Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules
fatal: sha1 information is lacking or useless (C4/Circulation.pm).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules
Comment 18 Kyle M Hall 2015-04-23 16:22:58 UTC Comment hidden (obsolete)
Comment 19 Kyle M Hall 2015-04-23 16:28:07 UTC Comment hidden (obsolete)
Comment 20 Kyle M Hall 2015-04-23 16:28:17 UTC Comment hidden (obsolete)
Comment 21 Katrin Fischer 2015-05-04 20:36:59 UTC
Sorry, but the second patch doesn't apply:

$ git bz apply 9805
Bug 9805 - Lost items are un-lost if returned, but not if renewed.

38432 - Bug 9805 - Lost items are un-lost if returned, but not if renewed.
38433 - Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 9805 - Lost items are un-lost if returned, but not if renewed.
Applying: Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules
fatal: sha1 information is lacking or useless (C4/Circulation.pm).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 9805 [QA Followup] - Control renewing and finding of list items via circ rules
The copy of the patch that failed is found in:
   /home/katrin/kohaclone/.git/rebase-apply/patch
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Patch left in /tmp/Bug-9805-QA-Followup---Control-renewing-and-findin-VqfKfD.patch
Comment 22 Kyle M Hall 2015-12-04 13:59:31 UTC Comment hidden (obsolete)
Comment 23 Kyle M Hall 2015-12-04 13:59:45 UTC Comment hidden (obsolete)
Comment 24 Kyle M Hall 2015-12-04 14:00:23 UTC Comment hidden (obsolete)
Comment 25 Katrin Fischer 2015-12-06 20:15:40 UTC
Hi Kyle,

some complaints form the QA script:

 FAIL	C4/Circulation.pm
   FAIL	  spelling
		 neccessary  ==> necessary
   FAIL	  valid
		BEGIN failed--compilation aborted 
		Compilation failed in require 
		Global symbol "$borrower" requires explicit package name 

Also: HoldsQueue.t is failing:

perl t/db_dependent/HoldsQueue.t 
1..23
Global symbol "$borrower" requires explicit package name at /home/katrin/kohaclone/C4/Circulation.pm line 2939.
Compilation failed in require at /home/katrin/kohaclone/C4/Overdues.pm line 30.
BEGIN failed--compilation aborted at /home/katrin/kohaclone/C4/Overdues.pm line 30.
Compilation failed in require at /home/katrin/kohaclone/C4/Members.pm line 29.
BEGIN failed--compilation aborted at /home/katrin/kohaclone/C4/Members.pm line 29.
Compilation failed in require at t/db_dependent/HoldsQueue.t line 19.
BEGIN failed--compilation aborted at t/db_dependent/HoldsQueue.t line 19.
# Looks like your test exited with 255 before it could output anything.
Comment 26 Kyle M Hall 2016-01-12 15:40:28 UTC Comment hidden (obsolete)
Comment 27 Kyle M Hall 2016-01-12 15:40:37 UTC Comment hidden (obsolete)
Comment 28 Kyle M Hall 2016-01-12 15:40:40 UTC Comment hidden (obsolete)
Comment 29 Jonathan Druart 2016-01-13 11:42:53 UTC
Please provide a complete test coverage for these changes.
Comment 30 Kyle M Hall 2016-02-03 17:08:59 UTC Comment hidden (obsolete)
Comment 31 Kyle M Hall 2016-02-03 17:59:40 UTC Comment hidden (obsolete)
Comment 32 Kyle M Hall 2016-02-03 17:59:48 UTC Comment hidden (obsolete)
Comment 33 Kyle M Hall 2016-02-03 17:59:52 UTC Comment hidden (obsolete)
Comment 34 Jonathan Druart 2016-03-01 13:11:59 UTC
t/db_dependent/Circulation/Renewal.t (Wstat: 65280 Tests: 2 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 7 tests but ran 2.
Comment 35 Kyle M Hall 2016-03-08 13:01:26 UTC Comment hidden (obsolete)
Comment 36 Kyle M Hall 2016-03-08 13:01:34 UTC Comment hidden (obsolete)
Comment 37 Kyle M Hall 2016-03-08 13:01:37 UTC Comment hidden (obsolete)
Comment 38 Kyle M Hall 2016-03-08 13:02:27 UTC
(In reply to Jonathan Druart from comment #34)
> t/db_dependent/Circulation/Renewal.t (Wstat: 65280 Tests: 2 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 7 tests but ran 2.

All the tests passed for me! Can you please try again?
Comment 39 Jonathan Druart 2016-03-09 10:28:51 UTC
t/db_dependent/Circulation/Renewal.t .. 1/7 DBD::mysql::st execute failed: Unknown column 'me.hold_fulfillment_policy' in 'field list'

The Schema is wrong, you are adding default_branch_circ_rules.hold_fulfillment_policy, which is not in master.
Comment 40 Kyle M Hall 2016-03-14 12:49:31 UTC
(In reply to Jonathan Druart from comment #39)
> t/db_dependent/Circulation/Renewal.t .. 1/7 DBD::mysql::st execute failed:
> Unknown column 'me.hold_fulfillment_policy' in 'field list'
> 
> The Schema is wrong, you are adding
> default_branch_circ_rules.hold_fulfillment_policy, which is not in master.

Doh! I must not have rebuild the schema on a stock community database! I'll get that fixed up!
Comment 41 Kyle M Hall 2016-03-14 12:55:59 UTC
Created attachment 49091 [details] [review]
Bug 9805 - Lost items are un-lost if returned, but not if renewed.

If an item has a lost status, that status is removed when the item
is returned. However, it is not removed if the item is renewed.

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Browse to the circ rules
4) Note the "Renew lost?" and "Renewal marks lost found" rules
5) Set and test each of the rules both ways for the rules for all libraries
6) Repeat but for a specific branch this time

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Comment 42 Kyle M Hall 2016-03-14 12:56:09 UTC
Created attachment 49092 [details] [review]
Bug 9805 - Update Schema
Comment 43 Kyle M Hall 2016-03-14 12:56:12 UTC
Created attachment 49093 [details] [review]
Bug 9805 - Unit Tests
Comment 44 Jonathan Druart 2016-03-14 15:53:31 UTC
 FAIL   C4/Circulation.pm
   FAIL   valid
                "my" variable $borrower masks earlier declaration in same scope 

$borrower is already defined few lines before.
It does not seem necessary to call GetMember, GetMemberDetails has been called just before.
Comment 45 Kyle M Hall 2016-03-15 11:01:22 UTC
Created attachment 49165 [details] [review]
Bug 9805 [QA Followup] - Stop calling GetMember repeatedly
Comment 46 Jonathan Druart 2016-03-17 11:20:42 UTC
(In reply to Kyle M Hall from comment #45)
> Created attachment 49165 [details] [review] [review]
> Bug 9805 [QA Followup] - Stop calling GetMember repeatedly

Kyle, This change looks safe, but it's very hard to say it won't introduce a regression. The $borrower var is passed from a sub to another without being "refreshed" like it was before this patch. This means we could use an outdated data.
Comment 47 Katrin Fischer 2016-03-24 06:59:15 UTC
Moving this to Failed QA for now - waiting for Kyle's response to comment#46
Comment 48 Kyle M Hall 2016-04-19 10:58:15 UTC
(In reply to Jonathan Druart from comment #46)
> (In reply to Kyle M Hall from comment #45)
> > Created attachment 49165 [details] [review] [review] [review]
> > Bug 9805 [QA Followup] - Stop calling GetMember repeatedly
> 
> Kyle, This change looks safe, but it's very hard to say it won't introduce a
> regression. The $borrower var is passed from a sub to another without being
> "refreshed" like it was before this patch. This means we could use an
> outdated data.

I do not believe this is a valid concern. There is no reason to suspect there could be any problems caused by this. If we force each subroutine in Koha to fetch all db data with each call, we will continue to make Koha slower and slower. If you have a specific scenario in mind where this will cause an issue, I'm certainly open to amending my position. Otherwise I we should keep this patch to improve speed and efficiency.
Comment 49 Katrin Fischer 2016-05-08 11:30:04 UTC
This patch no longer applies (see below)

Jonathan, do you oppose to continue testing this as is? Should we discuss more widely?

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 9805 - Lost items are un-lost if returned, but not if renewed.
Using index info to reconstruct a base tree...
M	C4/Circulation.pm
M	admin/smart-rules.pl
M	installer/data/mysql/kohastructure.sql
M	installer/data/mysql/updatedatabase.pl
M	koha-tmpl/intranet-tmpl/prog/en/includes/strings.inc
M	koha-tmpl/intranet-tmpl/prog/en/modules/admin/smart-rules.tt
M	koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/smart-rules.tt
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/admin/smart-rules.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/includes/strings.inc
Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
Auto-merging installer/data/mysql/kohastructure.sql
Auto-merging admin/smart-rules.pl
CONFLICT (content): Merge conflict in admin/smart-rules.pl
Auto-merging C4/Circulation.pm
Failed to merge in the changes.
Comment 50 Jonathan Druart 2016-05-09 11:33:49 UTC
(In reply to Kyle M Hall from comment #48)
> (In reply to Jonathan Druart from comment #46)
> > (In reply to Kyle M Hall from comment #45)
> > > Created attachment 49165 [details] [review] [review] [review] [review]
> > > Bug 9805 [QA Followup] - Stop calling GetMember repeatedly
> > 
> > Kyle, This change looks safe, but it's very hard to say it won't introduce a
> > regression. The $borrower var is passed from a sub to another without being
> > "refreshed" like it was before this patch. This means we could use an
> > outdated data.
> 
> I do not believe this is a valid concern. There is no reason to suspect
> there could be any problems caused by this. If we force each subroutine in
> Koha to fetch all db data with each call, we will continue to make Koha
> slower and slower. If you have a specific scenario in mind where this will
> cause an issue, I'm certainly open to amending my position. Otherwise I we
> should keep this patch to improve speed and efficiency.

Of course it's a valid concern :)
It's the same problematic we have for caching.
I don't suggest to "fetch all db data with each call", but we need to take care of the obsolescence of the data we manipulate.
You are fetching the patron info using GetMemberDetails, which returns accounting data, but AddRenewal modify these infos. At some point your $borrower is obsolete. For instance if SendCirculationAlert (which does not refetch patron infos) needs to access the accounting infos to sent the letter and decide to get if from $borrower, we will have a very hard to debug issue.

It would make more sense to have this kind of patches on a separate bug report, not to block the integration of this bugfix into master.
Comment 51 Karl Holten 2016-06-16 15:59:38 UTC
Any chance we can resolve whatever refactoring or whatever needs to be done for this in some other ticket, as suggested by Jon? There are plenty of items at our consortium that are still marked as "lost" even after someone renewed them, and getting a fix so that this doesn't continue to happen would be very much appreciated.

Karl
Comment 52 Tomás Cohen Arazi 2016-06-16 16:13:47 UTC
(In reply to Karl Holten from comment #51)
> Any chance we can resolve whatever refactoring or whatever needs to be done
> for this in some other ticket, as suggested by Jon? There are plenty of
> items at our consortium that are still marked as "lost" even after someone
> renewed them, and getting a fix so that this doesn't continue to happen
> would be very much appreciated.
> 
> Karl

Sure!
Comment 53 Beth Lovallo 2017-10-02 13:56:52 UTC
Any movement on this bug? We are new to Koha, and just ran into issues of staff renewing items and the item is still lost with a bill. We would like to keep the history, so reluctant to check in and check out again. 
Thanks!
Beth
Comment 54 SiobhanC 2019-01-25 09:11:33 UTC
I'd also be interested in an update on this - we are using DefaultLongOverdueLostValue to automatically update item status. We allow renewal of these items, in the staff client and OPAC, but when items are renewed, the lost status remains which means that fines are not applied and overdue notices are not sent. There is talk of a system pref for removing lost status when items renewed - will this be in a future release?
Comment 55 Katrin Fischer 2019-04-03 20:16:29 UTC
(In reply to SiobhanC from comment #54)
> I'd also be interested in an update on this - we are using
> DefaultLongOverdueLostValue to automatically update item status. We allow
> renewal of these items, in the staff client and OPAC, but when items are
> renewed, the lost status remains which means that fines are not applied and
> overdue notices are not sent. There is talk of a system pref for removing
> lost status when items renewed - will this be in a future release?

At the moment, there is no testable code for this bug. There have also been some questions we have not been sure about. 

Would you want to be able to renew all lost items with any lost status (long overdue or lost with replacement charge applied treated the same)?

At the moment we have different ideas how this should work:

- lost items remain lost after renewing
- renewing an item already marked lost should not be possible
- renewing a lost item should be possible and remove lost status
- renewing a lost item should be possible and not remove lost status 

Maybe it would make sense to differentiate behaviour for long overdue and lost by patron?

In this case we'd probably need some YAML like preference or one that aloows to list different lost status.
Comment 56 Wendy Sharkey 2019-04-04 13:27:59 UTC
In my very humble opinion if a lost item is renewed then it is no longer lost. If renewal is allowed then should it not be checked out and due back on a given date? Trouble with that is that could allow patrons to hang onto an item for years.
Not allowing a lost item to be renewed would be a safer option, then staff either get to check it back in or change the status manually.
Comment 57 SiobhanC 2019-04-10 07:33:30 UTC
Katrin's comment: Maybe it would make sense to differentiate behaviour for long overdue and lost by patron?

Yes, this is what I would like to see. I agree that 'lost by patron' items shouldn't be able to be renewed. However, for long overdue items that are auto-changed to lost (to enable us to easily identify them for invoicing) it would be good if they can have the 'not returned' status removed at the point of renewal. If this status isn't removed then the user doesn't receive notices. 

This would be a much bigger change, but could a new status category of overdue be introduced? Then the differentiation between overdue/lost would be easier.
Comment 58 Kim Robbins 2019-06-05 19:01:12 UTC
I would like to see the Long Overdue(Lost) and Lost status changed when the item is renewed. We do not allow our patrons to renew lost items but our staff is allowed to override the renewal limit and set a new due date. It is confusing to staff because we can see the new due date but the status is still Lost.
Comment 59 Christopher Brannon 2020-02-14 20:09:11 UTC
In my humble opinion, I think:

1) There should be a preference as to whether or not lost items are renewed.  Some libraries want that, others do not.

2) There should be a preference as to whether or not patrons can renew lost items via OPAC/SIP/Self Check.

3) There should be a preference as to whether or not there should be a warning when renewing a lost item.

4) There should be a preference as to whether or not the Renew all button/Select all link includes lost items.

5) There should be a preference as to whether or not the lost fee is refunded on renewal.
Comment 60 Christopher Brannon 2020-10-05 18:41:16 UTC
Would like to see some traction on this.  This bug seems to be stalled.
Comment 61 Azucena Aguayo 2020-10-05 19:03:14 UTC
It would be helpful to have this type of functionality. We have patrons that ignore due and overdue notices. Once they are billed then they call the library expecting to have their lost charges dropped and items renew.
Comment 62 Cheryl 2021-02-10 21:14:15 UTC
So with this fix, if the lost item is renewed and the status of lost (long overdue lost) is taken off, what happens with the lost item cost? Does the patron still owe it? and if the patron still owes the lost item cost after renewing the item, and then returns the item, does that mean that they do not get a refund for the item, since the item was not in a lost status at the time of return? 

It seems like some libraries would want to be able to renew lost items, but also to refund the lost item cost if the item is returned OR renewed. (Our library does not allow renewals on lost items because if you renew a lost item, the lost item cost stays on there and we don't want that.) 

We are okay with how it works for us now (no renewal of lost items), but I wanted to bring up the issue of the lost status coming off when the item is renewed, and then the patron possibly not being refunded if the item is returned later.
Comment 63 Christopher Brannon 2021-02-10 21:26:45 UTC
(In reply to Cheryl from comment #62)
> So with this fix, if the lost item is renewed and the status of lost (long
> overdue lost) is taken off, what happens with the lost item cost? Does the
> patron still owe it? and if the patron still owes the lost item cost after
> renewing the item, and then returns the item, does that mean that they do
> not get a refund for the item, since the item was not in a lost status at
> the time of return? 
> 
> It seems like some libraries would want to be able to renew lost items, but
> also to refund the lost item cost if the item is returned OR renewed. (Our
> library does not allow renewals on lost items because if you renew a lost
> item, the lost item cost stays on there and we don't want that.) 
> 
> We are okay with how it works for us now (no renewal of lost items), but I
> wanted to bring up the issue of the lost status coming off when the item is
> renewed, and then the patron possibly not being refunded if the item is
> returned later.

At the very least, there should be an option as to whether or not the charge is maintained if the item is checked in or renewed.  Our libraries don't charge the lost price if the item is returned.  We simply want our things back.  Some libraries refund the price, but retain the late fees, because, after all, they were very late.

Personally, I think it is wrong to charge a replacement cost for something that is returned.  Late fees, yes, absolutely keep them on the patron account.  But charging for the replacement cost after it is returned seems like theft.  UNLESS the item has actually been replaced.  THEN the cost should be maintained.

Wouldn't it be nice if there was a way to indicate on an item record if the item was replaced?  Then Koha would know if maintaining the cost of replacement is justified.
Comment 64 Aleisha Amohia 2024-02-27 00:53:27 UTC
Created attachment 162473 [details] [review]
Bug 9805: Lost items are un-lost if returned, but not if renewed.

If an item has a lost status, that status is removed when the item
is returned. However, it is not removed if the item is renewed.

Test Plan:
1) Apply this patch
2) Install database updates
3) Browse to the circ rules
4) Note the "Renew lost?" and "Renewal marks lost found" rules under default checkout hold and return policy
5) Set and test each of the rules both ways for the rules for all libraries

Sponsored-by: Waikato Institute of Technology
Comment 65 Aleisha Amohia 2024-02-27 00:54:06 UTC
One of our libraries uses this enhancement in production so I've rebased it for main - it has not incorporated the discussion above and is not ready for testing.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805
bugs.koha-community.org
CC-MAIN-2024-38
151276
application/http; msgtype=response
sha1:AJRX5F4A5CZRDCLMU66HCNQM2MVYVGHE
<urn:uuid:9ea132ef-933f-4a82-a024-c7c85b650909>
2024-09-13T12:10:17Z
72.14.190.217
text/html
sha1:YR3GZYNHARLRAIT5IHBC3GR5SHIA5K6Z
<urn:uuid:a41084e0-834b-4e41-a2c9-9009dd2c7cfe>
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805
response
<urn:uuid:702e74e1-b669-42ae-b7fc-9573b28303cb>
isPartOf: CC-MAIN-2024-38
publisher: Common Crawl
description: Wide crawl of the web for September 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-154
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/