Summary: | SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO | ||
---|---|---|---|
Product: | Koha | Reporter: | Joonas Kylmälä <joonas.kylmala> |
Component: | Self checkout | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | andrew, blawlor, carthur, cbrannon, edward.m.veal, kkrueger, nick, sbarter |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21572 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7090 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Joonas Kylmälä
2019-10-28 11:37:26 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. (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. I wonder if two things need to be addressed on this topic. I think it is ridiculous to allow just anyone to grab an item off a hold shelf and check it out when the person it is on hold for has been notified. That said: 1) There should be an option in settings to prevent this. If a library decides to just blanket allow this, then they can. 2) There should be a proxy setting for SCO. If a patron plans to have a proxy, the card number of that proxy should be listed in their account. When the proxy checks out the item that is on hold for someone else, it will confirm that they are checking out on behalf of the person it is on hold for, and the item is checked out on the holder's account, with a note that it was checked out by that proxy. This would also put in some ground work for functionality behind practices that libraries already do. Many libraries note that certain people can pick up holds for them. But it is just a note in their account. This would give this practice a little more teeth. See bug 39658 for hold proxies, which are a great idea but larger than the scope of this bug. ByWater has been seeking funding to extend the AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP sysprefs so that they each have 3 possible settings: - Do not allow checkout of Pending or Waiting holds - Allow checkout of Pending but not Waiting holds - Allow checkout of Pending and Waiting holds https://bywatersolutions.com/crowdsourcing/hold-prompts This maintains all currently possible functionality and adds some new flexibility for both Koha's web-based selfcheck and SIP selfchecks. |