Hold targeter ignoring closed settings when only local copies

[Steve Callender]

I found a situation where the hold targeter would ignore the circ.holds.target_when_closed_if_at_pickup_lib setting if the only potential holds for an item were only items at the pickup library.

The code looks like it was creating a list of closed org units based on potential items, and removing out the local org unit in order to have a secondary settings check for the pickup library. If there were no outside org units to check first due to no outside copies, it would just skip the whole subroutine and never apply the second setting.

I believe this patch should address that. Thank you Mike Rylander for the eyes on this.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=d29289d5c44917ca84ae91ebe91bf4fa2f1af0e7

[Steve Callender (stevecallender)]

Just a follow-up, I've seen this probably come up many times now.

The symptom is, if you are closed or all your branches are closed, and you are set to not process holds during closed times, but yet you are still occasionally seeing a random item pop up on the pull list, this is more than likely the bug you are hitting.

[Rogan Hamby (rogan-hamby)]

I might need a better testing plan or I don't understand the replication of the bug quite right.

Using concerto I took all the copies for bib 250, assigned circ_lib to BR3, set the libraries hour's to all closed and circ.holds.target_when_closed_if_at_pickup_lib to false for the consortium.

Pre Patch - targeted a copy on creation, set target_copy to null and ran hold targeted, did not select a copy

Post Patch - identical behavior

[Dawn Dale (ddale)]

Using concerto, I set bib 90 copies to missing except the copies at BR1. I entered closed dates for BR1. I placed a hold for patron 99999303411 to be picked up at SL1. Assuming the holds targeter ran overnight, the hold was not on the pull list for BR1. This is the behavior I would expect. Agreeing with Rogan that I might not fully understand the issue, but I would consider this fixed but I don't want to sign off on it until I am sure I understand the issue.

[Terran McCanna (tmccanna)]

Steve - can you write steps to recreate the problem on a current test server with Concerto data (without the patch)?

I wonder if there is something else that has been changed that has already resolved the issue? (Like Hopeless Holds? I haven't looked at the code, but I would assume that the holds in this scenario should appear there rather.)

[Terran McCanna (tmccanna)]

Marking this one Won't Fix since several people haven't been able to recreate the problem without the patch. This can always be revisited if a way is found to trigger the problem.