Bug 9906 - Holds Return Policy and Local Hold Item Types not working as expected
Summary: Holds Return Policy and Local Hold Item Types not working as expected
Status: RESOLVED DUPLICATE of bug 10243
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low major
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-22 20:15 UTC by HB-NEKLS
Modified: 2013-05-16 16:53 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:
Circulation function:


Attachments
Basehor's Local Hold Settings (56.85 KB, image/png)
2013-05-06 17:16 UTC, HB-NEKLS
Details
Leavenworth's hold policy settings (57.22 KB, image/png)
2013-05-06 17:17 UTC, HB-NEKLS
Details

Note You need to log in before you can comment on or make changes to this bug.
Description HB-NEKLS 2013-03-22 20:15:43 UTC
The Holds Return Policy table (new to us as we just upgraded to 3.8.8 a few weeks ago) has proven to have unexpected ramifications for NExpress libraries. When items with LOCAL HOLD item types are returned at another library, these LOCAL HOLD items are being selected to fill ineligible holds.

EXPLANATION:
NExpress has two kinds of restricted item types defined: LOCAL HOLD, which only allows requests from patrons having the same HOME LIBRARY as the item to trigger holds, and WALK IN, which disallows holds entirely. There are three specific item types for each, depending on the material, which are defined by the owning library in Koha.:

1 LOCAL HOLD BOOK
2 LOCAL HOLD MOVIE
3 LOCAL HOLD OTHER

1 WALKIN BOOK
2 WALKIN MOVIE
3 WALKIN OTHER

SITUATION:
We are seeing the case where LOCAL HOLD items that are returned at a library other than its home library are being selected from the holds queue to fill holds for patrons at the library. In other words, when the hold patron's home library matches the Current Location, a hold is triggered; the correct behavior is that a hold is triggered ONLY when the hold patron's home library matches the Home Library location of an item.

The three LOCAL HOLD item types are not being correctly observed when such an item is checked in at a library other than the item's home library. The LOCAL HOLD restricted-hold item types were not taken into account when formulating the new Return Policy table, which has this explanatory note: "…these policies are based on the patron's home library, not the library where the hold is being placed."

This is the problem. The item's home library, not the patron's home library, is what needs to determine the hold restriction for LOCAL HOLD item type.
Comment 1 Katrin Fischer 2013-03-22 22:25:39 UTC
Heather, sorry, but I am not sure I could reproduce the problem from the description. Could you give a step by step description of how to reproduce it, starting with the settings you chose in configuration?
Comment 2 HB-NEKLS 2013-05-06 17:16:31 UTC
Created attachment 17966 [details]
Basehor's Local Hold Settings
Comment 3 HB-NEKLS 2013-05-06 17:17:03 UTC
Created attachment 17967 [details]
Leavenworth's hold policy settings
Comment 4 HB-NEKLS 2013-05-06 17:17:48 UTC
Katrin, 
I just saw your response when I came back to relook at this bug report. 

When you check in a local hold item from library A at library B, if a patron at library B has a hold on it, a hold is triggered for a patron at library B. This is unexpected behavior. Items with the local hold item type are only supposed to trigger holds for patrons at the item's HOME library. 

I screencasted an example, but can't attach the video file here and also realized I don't want all the patrons names exposed online, so I can't even share the video file. 

The testing process: 

I set my home library to Leavenworth and checked in a Basehor local hold item. 
The process triggered a hold for a Leavenworth patron. 

The expected behavior should have been to trigger a hold for ONLY a Basehor patron OR prompt the library to return the item back to Basehor. That behavior has always been previously how local holds worked in the past on Koha. 

I am also attaching screenshots of the holds policy by item type for the two libraries I was using to test this situation with. 

Please let me know if you need further detail for testing.
Comment 5 Katrin Fischer 2013-05-11 12:20:19 UTC
Hi Heather, I won't have time to test this, but maybe someone else can confirm?
Comment 6 Melia Meggs 2013-05-16 16:53:46 UTC
I think was resolved with the patch for Bug 10243, so I am closing this out.

*** This bug has been marked as a duplicate of bug 10243 ***