The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item.
Created attachment 22965 [details] [review] Bug 11258 - Holds queue is still making transfer requests that contradict the branch holds policy The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item. Test Plan: 1) Create a test record with 2 items with different itemtypes 2) Set the Default holds policy by item type for the first item to "From any library" 3) Set the Default holds policy by item type for the second item to "From home library" 4) Place a record level hold for a patron from another library, but for pickup at the same library as the item is from 5) Rebuild the holds queue 6) View the holds queue, note the item is listed, though this patron cannot place a hold on this item 7) Apply this patch 8) Repeat step 5, note the hold is no longer in the queue
Created attachment 22970 [details] [review] Bug 11258 - Holds queue is still making transfer requests that contradict the branch holds policy The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item. Test Plan: 1) Create a test record with 2 items with different itemtypes 2) Set the Default holds policy by item type for the first item to "From any library" 3) Set the Default holds policy by item type for the second item to "From home library" 4) Place a record level hold for a patron from another library, but for pickup at the same library as the item is from 5) Rebuild the holds queue 6) View the holds queue, note the item is listed, though this patron cannot place a hold on this item 7) Apply this patch 8) Repeat step 5, note the hold is no longer in the queue
Created attachment 22971 [details] [review] Bug 11258 - Holds queue is still making transfer requests that contradict the branch holds policy The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item. Test Plan: 1) Create a test record with 2 items with different itemtypes 2) Set the Default holds policy by item type for the first item to "From any library" 3) Set the Default holds policy by item type for the second item to "From home library" 4) Place a record level hold for a patron from another library, but for pickup at the same library as the item is from 5) Rebuild the holds queue 6) View the holds queue, note the item is listed, though this patron cannot place a hold on this item 7) Apply this patch 8) Repeat step 5, note the hold is no longer in the queue
Created attachment 23011 [details] [review] Bug 11258 - Holds queue is still making transfer requests that contradict the branch holds policy The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item. Test Plan: 1) Create a test record with 2 items with different itemtypes 2) Set the Default holds policy by item type for the first item to "From any library" 3) Set the Default holds policy by item type for the second item to "From home library" 4) Place a record level hold for a patron from another library, but for pickup at the same library as the item is from 5) Rebuild the holds queue 6) View the holds queue, note the item is listed, though this patron cannot place a hold on this item 7) Apply this patch 8) Repeat step 5, note the hold is no longer in the queue Signed-off-by: Liz Rea <liz@catalyst.net.nz> automated tests pass, functional tests pass. Bug replicated, eradicated by patch.
I am sorry, but I can't seem to reproduce the bug on current master. I followed the test plan, but my holds queue entry is the same before and after applying the patch. >1) Create a test record with 2 items with different itemtypes Branches, itemtype, barcode Midway, Books, t1 Midway, Computer files, t2 >2) Set the Default holds policy by item type for the first > item to "From any library" Midway: Books, from any library >3) Set the Default holds policy by item type for the second > item to "From home library" Midway: Computer files, from home library >4) Place a record level hold for a patron from another library, > but for pickup at the same library as the item is from Switched to Riverside, placed a title level hold for a Riverside patron, pickup location is Midway. >5) Rebuild the holds queue Entry reads: Books, t1 or any available >6) View the holds queue, note the item is listed, though this > patron cannot place a hold on this item I couldn't reproduce this. >7) Apply this patch >8) Repeat step 5, note the hold is no longer in the queue
I set up test plan in production as described in ticket. Results positive. Available item with Local Hold was correctly x'ed out in holdings table, and hold did not show up on pick list for patron wanting pickup location at owning library. Checked in another item without hold restriction, which DID show up correctly on pick list. So the behavior is now as expected, and desired. Patch eliminated bug.
(In reply to Katrin Fischer from comment #5) > >6) View the holds queue, note the item is listed, though this > > patron cannot place a hold on this item > > I couldn't reproduce this. And me I see it before and after applying the patch (I rebuilt the holds queue).
Kyle, I think we need help here - could it be something is missing from the test plan?
(In reply to Katrin Fischer from comment #8) > Kyle, I think we need help here - could it be something is missing from the > test plan? Nope, I followed the test plan with a fresh database and was able to recreate the bug, and also show the patch resolves it. Here is a video demonstration: http://screencast.com/t/0PBAfJkf5 After I demonstrate the bug, apply the patch and rebuild the holds queue, you'll see no items in the holds queue. This is because I forgot that Reference items are not holdable. So post-patch, neither item is holdable by that patron, and the holds queue *should* be empty. After that, I make Reference items holdable, rebuild the holds queue again, and a hold request for the Reference item shows up, which is the correct behavior as well.
Created attachment 25224 [details] [review] Bug 11258 - Holds queue is still making transfer requests that contradict the branch holds policy The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item. Test Plan: 1) Create a test record with 2 items with different itemtypes 2) Set the Default holds policy by item type for the first item to "From any library" 3) Set the Default holds policy by item type for the second item to "From home library" 4) Place a record level hold for a patron from another library, but for pickup at the same library as the item is from 5) Rebuild the holds queue 6) View the holds queue, note the item is listed, though this patron cannot place a hold on this item 7) Apply this patch 8) Repeat step 5, note the hold is no longer in the queue Signed-off-by: Liz Rea <liz@catalyst.net.nz> automated tests pass, functional tests pass. Bug replicated, eradicated by patch.
Created attachment 27267 [details] [review] [PASSED QA] Bug 11258 - Holds queue is still making transfer requests that contradict the branch holds policy The holds queue generator is still making requests that are not allowed. Previously it was making transfer requests that were not allowed. Currently, it is still making requests where the pickup branch is the same as the item's branch but not the patron's branch, even if there is a "Default holds policy by item type" rule that states this item can only fill holds for patron's of the same branch as the item. Test Plan: 1) Create a test record with 2 items with different itemtypes 2) Set the Default holds policy by item type for the first item to "From any library" 3) Set the Default holds policy by item type for the second item to "From home library" 4) Place a record level hold for a patron from another library, but for pickup at the same library as the item is from 5) Rebuild the holds queue 6) View the holds queue, note the item is listed, though this patron cannot place a hold on this item 7) Apply this patch 8) Repeat step 5, note the hold is no longer in the queue Signed-off-by: Liz Rea <liz@catalyst.net.nz> automated tests pass, functional tests pass. Bug replicated, eradicated by patch. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> I finally managed to reproduce this, patch works as described. Passes tests and QA script, provided tests fail without patch, but succeed with the patch.
Pushed to master. Thanks, Kyle!
Pushed to 3.14.x, will be in 3.14.10
Picked for 3.12.15!