Evergreen

Comment 1 for bug 1866667

Revision history for this message

Josh Stompro (u-launchpad-stompro-org) wrote on 2020-03-10:

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://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Holds.pm;hb=f60f0562450569c2e46b1187392dbfede35faf79#l961

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

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://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Holds.pm;hb=f60f0562450569c2e46b1187392dbfede35faf79#l961

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