Comment 12 for bug 1430545

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
>