| 2013-01-11 01:04:38 |
James Fournie |
description |
Related bugs:
https://bugs.launchpad.net/evergreen/+bug/1046471
https://bugs.launchpad.net/evergreen/+bug/1064651
Evergreen: 2.2, Postgres 9.1
This is a bit convoluted, hopefully I can explain this properly.
When placing a hold, various methods check for possible copies and raise the no_ultimate_items error if there is no way that the hold will likely be fulfilled. These methods use something like this:
my %org_filter = create_ranged_org_filter(new_editor(), $selection_ou, $depth);
They then put the result in a big json_query call to get possible copies.
HOWEVER, copy-level holds don't do this. During a copy hold, only verify_copy_for_hold is called, which just does the permit hold stuff on that copy. That makes sense since, why would you ever want to check for a copy when you already have a copy for the copy hold. However, the main issue we're experiencing is that copy holds don't do any of this org_filter business, meaning that hold boundaries won't be respected properly on copy holds. This means that I can place a copy hold with any pickup library and it will be filled despite my hard boundaries.
There are a few possible solution, I am thinking a temporary fix will be to wrap verify_copy_for_hold in a _check_copy_hold_is_possible |
Related bugs:
https://bugs.launchpad.net/evergreen/+bug/1046471
https://bugs.launchpad.net/evergreen/+bug/1064651
Evergreen: 2.2, Postgres 9.1
This is a bit convoluted, hopefully I can explain this properly.
When placing a hold, various methods check for possible copies and raise the no_ultimate_items error if there is no way that the hold will likely be fulfilled. These methods use something like this:
my %org_filter = create_ranged_org_filter(new_editor(), $selection_ou, $depth);
They then put the result in a big json_query call to get possible copies.
HOWEVER, copy-level holds don't do this. During a copy hold, only verify_copy_for_hold is called, which just does the permit hold stuff on that copy. That makes sense since, why would you ever want to check for a copy when you already have a copy for the copy hold. However, the main issue we're experiencing is that copy holds don't do any of this org_filter business, meaning that hold boundaries won't be respected properly on copy holds. This means that I can place a copy hold with any pickup library and it will be filled despite my hard boundaries.
There are a few possible solutions, although a permanent solution would be a major rewrite of holds code, which Jason S. has discussed, and would probably be a good opportunity to integrate some relevant FulfILLment code. But, I am thinking a temporary fix will be to wrap verify_copy_for_hold in a _check_copy_hold_is_possible |
|
