hard boundaries not respected on copy holds

[James Fournie]

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