Bug 23909 - SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Self checkout (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 25703 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-28 11:37 UTC by Joonas Kylmälä
Modified: 2024-01-09 15:00 UTC (History)
3 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 Joonas Kylmälä 2019-10-28 11:37:26 UTC
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.
Comment 1 Andrew Fuerste-Henry 2019-10-28 12:47:00 UTC
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.
Comment 2 Joonas Kylmälä 2019-10-28 13:33:25 UTC
(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?
Comment 3 Joonas Kylmälä 2019-10-28 13:38:11 UTC
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?
Comment 4 Andrew Fuerste-Henry 2019-10-28 13:49:40 UTC
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.
Comment 5 Joonas Kylmälä 2019-10-28 13:55:05 UTC
(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?
Comment 6 Nick Clemens 2019-10-28 14:47:01 UTC
(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
Comment 7 Didier Gautheron 2022-04-27 12:47:28 UTC
*** Bug 25703 has been marked as a duplicate of this bug. ***
Comment 8 Katrin Fischer 2023-12-09 12:23:41 UTC
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?