Hi Martin and Alex, Here's my take on the whole thing, for what it's worth. 1) I think this is a bug and should not be switched on or off by a system preference. 2) The holding library should revert back to the one it was before the transfer. 3) I'm not sure if we should erase the old transfers at upgrade. Personally, if I worked in a library, I'd like to have a report of lost items currently in transfer and decide what I want to do with them (are they reserved? do I have more than one copy? how long ago were they declared lost? etc.) I think bugs 20844 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844) and 21754 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21754) should continue their QA process and hopefully be added in 18.11 before release. However, I think we should discuss the handling of holds and transfers throughout Koha regardless of how the lost status is set. I noticed you mentioned batchmod, pendingreserves and longoverdue. Whatever the way an item was marked as lost, whether manually or a cron or a batch modification, the management of pending reserves, waiting reserves, transfers or pending transfers should not differ. At the time it was marked as lost, if the item's status was : - waiting reserve, this case should be handled bu 20844 - pending reserve, show an alert or have a report for problematic reserves. If there is more than one item, it's not a problem as the hold will be filled by another item; however, if the record only has one item, the library needs to call the user and/or request an ILL or whatever their process is for unfillable holds. - currently in transit, this case should be handled by 21754. (Does this also handle reserves that have "T" in the "found" column? I'm guessing yes, but just making sure.) - pending transfer, show an alert or have a report for problematic reserves, same as pending reserves. I didn't touch on rotating collections and stock rotation as I'm not sure how these affect transfers. I hope this helps your cogitation :) Regards, Caroline Caroline Cyr La Rose, M.L.I.S. Librarian / Head of Training and Support, inLibro caroline.cyr-la-rose@inLibro.com <mailto:caroline.cyr-la-rose@inLibro.com> Le 18-11-01 à 04 h 03, Renvoize, Martin a écrit :

Hi all,

I'm seeking some thoughts regarding 'Bug 21732 - If an item is marked as lost, any outstanding transfers should be cancelled <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21732>'.

Currently, there is no thought given to transfers when an item is marked as lost, an as such you may have lost items in the transfers queue. This bug aims to solve this by triggering a cancellation of the transfer at the point an item is marked as lost.

We have a few questions:

1) Should this be treated as an enhancement or a bug (If it's an enhancement then we would enable/disable it's functionality based upon a system preference. If it's a bug (as I advocate), then it would be always enabled and no system preference would be added) 2) If the items is 'in transit' where should the items holding library be set to when it is marked as lost (the from or to library). 3) If we consider this a bug, should we add handling for cleaning up the transfers table at upgrade time for any lost items.

Many thanks for your help,

*Martin Renvoize*

<https://www.ptfs-europe.com>

Development Team Manager

*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvoize@ptfs-europe.com

*Fax:* +44 (0) 800 756 6384

www.ptfs-europe.com

Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha