Feature: action.hold_request should datestamp the hold when targeter assigned a copy

[Blake GH]

We would like to know when a copy was targeted. This will enable us to decide to retarget a hold after X amount of time. It would be great if there was a library setting that will automatically retarget a hold after a configurable amount of time. We are finding that copies are getting targeted but never pulled. We don't know how long something has been targeted because the hold targeter continues to update the prev_check_time column. Perhaps a new timestamp column should be added to the schema?

[Galen Charlton (gmc)]

The table action.unfulfilled_hold_list keeps a record of holds that should have been filled by a current targeted copy but which were not filled. It is populated each time the hold targeter processes a hold for retargeting.

The hold targeter also consults the "Maximum library target attempts" library setting. If items at a given library have failed to pulled the number of times specified by that setting, the targeter will try exclude that library's copies from future consideration.

Does that give you enough to work with?

[Blake GH (bmagic)]

In order for a row to appear in action.unfulfilled_hold_list, a human needs to execute the "retarget" action?

[Mike Rylander (mrylander)]

Nope, the hold just has to be retargetted -- either prev_check_time-triggered or human-triggered. See line 1546 in Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm (master).

[Mike Rylander (mrylander)]

Also, regarding your initial wish, "[i]t would be great if there was a library setting that will automatically retarget a hold after a configurable amount of timeholds do retarget after," holds retarget every 24 hours. Today, you can change that by editing hold_targeter.pl, but a setting would be nice. Without more extensive development and a clear and consistent definition for the context org of a hold, such a setting would still have to be global.

[Jason Stephenson (jstephenson)]

It would be relatively trivial to make the time period a command line option to the hold targeter script, with 24h as the default if none is given.

[Mike Rylander (mrylander)]

Following up on Jason's comment, I'd be in favor of a settings server value
as a peer to the hold parallelism setting were I to have my druthers.

--miker

On Wed, Mar 11, 2015 at 9:54 AM, Jason Stephenson <
<email address hidden>> wrote:

> It would be relatively trivial to make the time period a command line
> option to the hold targeter script, with 24h as the default if none is
> given.
>
> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> https://bugs.launchpad.net/bugs/1430545
>
> Title:
> Feature: action.hold_request should datestamp the hold when targeter
> assigned a copy
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> We would like to know when a copy was targeted. This will enable us to
> decide to retarget a hold after X amount of time. It would be great if
> there was a library setting that will automatically retarget a hold
> after a configurable amount of time. We are finding that copies are
> getting targeted but never pulled. We don't know how long something
> has been targeted because the hold targeter continues to update the
> prev_check_time column. Perhaps a new timestamp column should be added
> to the schema?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1430545/+subscriptions
>

[Justin Hopkins (hopkinsju)]

I think the comment "[i]t would be great if there was a library setting that will automatically retarget a hold after a configurable amount of timeholds do retarget after," was meant to mean something different. More along the lines of "Ok, Library A, you've had X days to pull this hold we've targeted, let's see if a *different library* has this item and target it there instead"

[Jason Stephenson (jstephenson)]

Well, that's more or less what the hold targeter does, but it makes no guarantees on picking a different library.

It would be a simple thing to make the global setting a command line option or have it go in opensrf.xml.

An ou setting with behavior of picking a different library's copy would be much more involved. That's assuming that there is another library's copy to pick. As for context_ou, it sounds like the targeted copy's circ lib would be used.

[Blake GH (bmagic)]

I'm confused. Once the hold targeter has populated the current_copy column, I wasn't aware that it would automatically pick another copy after awhile. It sounds like you are saying that it does. Right now, /openils/bin/hold_targeter.pl will pass
 $storage->request('open-ils.storage.action.hold_request.targetable_holds.id_list', '24h');

Meaning: Every 24 hours, attempt to expand the pool of potential copies in the action.hold_copy_map. In addition to that, only pay attention to holds that haven't received attention in 24 hours (based on prev_check_time). This is the reason that newly cataloged items do not fill holds right away. This doesn't mean "Search for a different copy if capture_time is still null after x amount of time" does it?

[Jason Stephenson (jstephenson)]

It means attempt to find a new copy every 24 hours. I believe that includes holds that have no copy targeted already, but they should be targeted on every hold targeter run. (I was just looking at this yesterday for other reasons.)

If you're going 24 hours or more with an untargeted hold, that means there are no copies to fill it, if I read the code correctly yesterday and remember it correctly today.

[Jason Stephenson (jstephenson)]

BTW, just to clarify, one of the criteria in the query is capture_time is null, so yes, uncaptured holds are retargeted. That's kind of the point.

[Mike Rylander (mrylander)]

Ah, you misunderstand what the targetter does. It retargets the relevant
holds and records the fact that the hold was not pulled if it was
previously targeted. IOW, it /does/ mean "search for a different copy if
capture_time is still NULL" ... always has.

The setting that Galen mentions up-thread is designed to do approximately
what you want. You may also be interested in the Org Unit Target Weight
setting, and Hold Proximity Adjustment.

Regarding "newly cataloged items do not fill holds right away," there are
checkin modifiers that will look for local holds that the item might be
able to fill, and will retargets those holds so the copy gets on the
potentials list if it can.

HTH.

On Wed, Mar 11, 2015 at 10:53 AM, Blake GH <email address hidden>
wrote:

> I'm confused. Once the hold targeter has populated the current_copy
> column, I wasn't aware that it would automatically pick another copy after
> awhile. It sounds like you are saying that it does. Right now, /openils/bin/
> hold_targeter.pl will pass
> $storage->request('open-ils.storage.action.hold_request.targetable_holds.id_list',
> '24h');
>
> Meaning: Every 24 hours, attempt to expand the pool of potential copies
> in the action.hold_copy_map. In addition to that, only pay attention to
> holds that haven't received attention in 24 hours (based on
> prev_check_time). This is the reason that newly cataloged items do not
> fill holds right away. This doesn't mean "Search for a different copy if
> capture_time is still null after x amount of time" does it?
>
> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> https://bugs.launchpad.net/bugs/1430545
>
> Title:
> Feature: action.hold_request should datestamp the hold when targeter
> assigned a copy
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> We would like to know when a copy was targeted. This will enable us to
> decide to retarget a hold after X amount of time. It would be great if
> there was a library setting that will automatically retarget a hold
> after a configurable amount of time. We are finding that copies are
> getting targeted but never pulled. We don't know how long something
> has been targeted because the hold targeter continues to update the
> prev_check_time column. Perhaps a new timestamp column should be added
> to the schema?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1430545/+subscriptions
>

[Blake GH (bmagic)]

This is great! Thank you for clarifying those things. Hold logic is a hairy beast. I have done some testing and we are finding this scenario:

There are 15 copies in the hold_copy_map. The first copy targeted is the lowest proximity. I tell the system to "Find Another Target" and it doesn't choose a different copy from the list. It chooses the same one. Presumably because it has the lowest proximity. I went ahead and marked that copy missing which took it out of the list. Now all of the proximities are equal. When I tell it to "Find another copy" it does pick a different copy! We want the system to pick a different copy every 24 hours starting with the lowest proximity to the greatest proximity. Is that possible? At the very least, we don't want it to get stuck in a loop on the same copy because it has the lowest proximity.

[Blake GH (bmagic)]

I discovered that "Find another target" is not the same as letting the hold targeter cron job run! The hold targeter will in fact choose another copy from the pool regardless of the proximity! So, now that we have a better understanding of what is going on, I think that the current code is satisfying our needs. There are some scenarios that we could see some improvement for such as:

You print your pull list. You got to the shelf and you cannot find the matching barcode but you find another copy of the item. You check it in but the system didn't capture it because it's not the exact same item. A little UI would be great to force the hold to target the copy in hand instead.