Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent.
Some libraries would prefer that Koha allow the patron to check out the book even though it is meant to be on hold. I think this needs to be an option.
(In reply to Andrew Fuerste-Henry from comment #1) > Some libraries would prefer that Koha allow the patron to check out the book > even though it is meant to be on hold. I think this needs to be an option. Why? And is there a real library doing this? Are the patrons not angry when they have come to fetch a book for which they got an email about that it has arrived?
And to clarify this a bit more: waiting items cannot be checked out currently with SIP so this would make both of these checkout methods work the same way. Maybe you are thinking of the Reserved state, i.e. patron has placed a hold but it has not been confirmed by the library yet to be available for pickup?
I believe the thinking is that whenever possible the book should go to the patron who has it in-hand. I'm sure the patron who previously got a notice that their hold is available *is* angry when their item isn't there for them, but nonetheless I have known real libraries that do this. I'm not arguing that it's a good idea, just that it's something I've known libraries to do.
(In reply to Andrew Fuerste-Henry from comment #4) > I believe the thinking is that whenever possible the book should go to the > patron who has it in-hand. I'm sure the patron who previously got a notice > that their hold is available *is* angry when their item isn't there for > them, but nonetheless I have known real libraries that do this. I'm not > arguing that it's a good idea, just that it's something I've known libraries > to do. Would you be able to check with these libraries if they could just disable the holds completely because there doesn't seem to be any use of placing a hold in that case?
(In reply to Joonas Kylmälä from comment #5) > > Would you be able to check with these libraries if they could just disable > the holds completely because there doesn't seem to be any use of placing a > hold in that case? Often different workflows seem confusing, but I think there can be justifications here: i.e. a library allows a proxy to pick up holds I think you would need to send this to the mailing list to get opinions before making a change. The prefs seem pretty explicit about overriding 'waiting' so maybe a second setting in the pref
*** Bug 25703 has been marked as a duplicate of this bug. ***
I can understand the argument for items that haven't been set to waiting yet, but I think once we have sent out the mail to the user, it should not be able for someone else to check it out on the self check. The circulation desk is a different case. If proxy pick-up is allowed and wanted... how do you prevent patrons picking any item from the pick-up shelf they'd like to jump the queue on? But if this strictly needs to be configurable, maybe it should be something like: SCOAllowWaitingPickupByProxy?
If a patron has a hold on an title that is available on the shelf at 10 different branches, we should not block that title from being checked out at all branches. If there is a way around that, let me know. Otherwise I feel that it's important to have a preference to only block the item once the hold has been filled.
I was a bit confused after reading this the first time, so I will clarify. Yes, check outs should be blocked when they are in Waiting or Transit status. The issue is that Koha also blocks checkouts for holds/reserves that have not been found. If reserves.found is NULL the checkout should not be blocked.