Hold targeting weirdness in 2.11

[Kathy Lussier]

Evergreen version: master

I've been having trouble getting holds to capture on a VM running master. After testing further, it looks like there may be a problem with holds targeting in 2.11.

Here are the steps I followed.

- I built 2 VMs: one with the latest master and one with the latest code from the 2.10 branch. Each VM is loaded with the Concerto dataset and has no other development branches.

- I retrieve record 217 on each VM. It already has one title-level hold placed on it (id 235). I select the option to find another target for each hold, just to ensure that the hold has gone through the targeting process.

- On the 2.10 system, I get a barcode in the current copy column. On the master system, I get No Copy. On the 2.10 system, there are 12 eligible copies listed in action.hold_copy_map. on the master system, there are none.

Placing new holds on the record in master also do not result in any eligible copies.

I don't see any changes to the Concerto data set or specific pieces of data that explain why none of the copies on this record would be eligible to fill the hold.

I could be missing something, but the signs so far are pointing to a problem with holds targeting.

Another VM that was built with master as of August 23 appears to be working as expected.

[Kathy Lussier (klussier)]

One more data point. I see the following in the logs:

[2016-09-15 16:15:16] open-ils.storage [ERR :28516:action.pm:1597:] Processing of hold failed: Can't locate object method "is_available" via package "config::copy_status" at /usr/local/share/perl/5.18.2/OpenILS/Application/Storage/CDBI.pm line 181.

[Bill Erickson (berick)]

Signed off and merged to master:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1624025_copy_status_missing_field