Evergreen 3.4.2, OpenSRF 3.2.0, PostgreSQL 9.6 on Debian Buster (db is on Stretch).
When patron edits a hold and chooses a different pickup library, the hold retargets. This retarget appears to be the same as a staff-initiated "find another copy", and excludes the current copy.
Even if the originally targeted copy is still by far the best choice to fill the hold.
Even if all of the other copies are non-local, require crossing soft boundaries, etc.
Even if the new pickup location is actually *closer* to the originally targeted copy than the original pickup location was.
Even if the new pickup location is the *home* of the originally targeted copy.
Not theoretical, this just happened to one of our patrons. They placed a hold for System A, for pickup at Branch B. An available copy at System A, Branch A was immediately targeted. Appx two minutes later the patron changed their pickup location to System A, Branch A.
The system let go of the copy at System A, Branch A, and targeted a copy at System B, Branch A instead. Different system, crossing a soft boundary, ignoring the soft stalling interval, etc. Different town, 20 minute drive away, with a courier that only runs here twice a week.
While the best copy for the hold was already right there at the pickup library, on the shelf. Of course the patron happened to find it there when they came in to pickup something else, and had some (reasonable) comments to share on the matter.
Shouldn't a pickup library change be a "retarget everything again" event, rather than a forced "find another copy"?
Jeremiah, thanks for this bug report. I just tried this out on a 3.3.4 system and can confirm your findings.
I don't think this situation comes up all that often, since the automatic hold pickup selection works for most holds placed. But there must be a situation where it fails, because the alphabetically first pickup location in our list does get several holds a month where that wasn't the intended selection, it just happened to be the default for that one hold.
The new hold targeter does have a soft retarget option, which doesn't exclude the current copy as an option, and keeps that copy as a valid choice.
So it may be as simple as calling the specific retarget call with the soft interval set to 1 second. But that may not work in all cases, I think the soft retarget exits if the current copy is still valid. So in the case where changing the pickup library should cause a different copy to be chosen, that wouldn't work.
It seems like there may need to be another mode for the retargeter, a refresh mode.
I wonder if clearing the current_copy before calling retarget would be enough?
https:/
There is logic there to handle changing the pickup lib for copies that are in transit or on the hold shelf.
It may make sense to add some logic looking for a pickup_lib change, where the status is waiting for copy, that clears the target_copy. A pickup lib change looks like it always triggers a retarget, unless the item is already captured. I'm not sure if the prev_check_time also needs to be cleared.
For libraries that use the hold target loops feature... I'm not sure that this would work out, but I'm not sure that any retarget tries to handle that in a special way. Hold target loops is a feature that lets a hold cycle through targeting copies at all available copy locations a certain number of times. I believe that a retarget will always try and target a copy at the next location in that mode, but maybe there is an exception for copies at the pickup lib.
Josh