Item Recall Email Notice goes out multiple times for same item.

[Dale Rigney]

Tested on Evergreen 3.0

When using hold driven recalls patrons get multiple "Item Recall Email Notice". The Hold Driven recall process looks at the Duration filed on the circulation to determine if the circulation is qualified for the recall process and send the patron an "Item Recall Email Notice" e-mail. When the process is complete the duration filed has not changed so when the hold is reprocessed (usually every 24 hours or so) the same circulation is checked and the notices goes out again to the patron.

Here were the settings used:

circ.holds.recall_fine_rules = "[0.00,\"1 day\",0.00]"
circ.holds.recall_threshold = "2 months"
circ.holds.recall_return_interval = "2 weeks"

When the process is run it checked for targeted items that have a duration of over 2 months. Qualifying circulations have the due date changed and a notice e-mailed to them. When the hold is re-processed the duration of the circulation is still the same so the same qualifying circulation is targeted and another notice is sent to the patron.

We feel that the patron should only get one notice per item that has been targeted in the process.

[Jeff Davis (jdavis-sitka)]

We're seeing this behavior on 3.3.4.

The hold targeter generates recall email events using the open-ils.trigger.event.autocreate method. This method does not check for any pre-existing events with the same event def + target. I'm not sure if that's a bug or by design.

The open-ils.trigger.active.event.autocreate.batch method *does* avoids creating multiple events with the same event_def + target, so we could use that method to generate recall emails instead. We would need to include the target ID in the filter param. This doesn't feel like the right approach, though.

[Steve Callender (stevecallender)]

Just to add to this, the repeat_delay variable on the definition is also not considered when the event is fired off, so that cannot be used as a means to limit the event from firing off every time the hold targeter is processing the hold, but that could be a way to correct this. Teach it to check for events, target that are newer than the repeat_delay.