Tested in Evergreen 3.1
I'm seeing events blocked from being created if there is a repeat_delay but a different event falls into that window and the events share the same target ID.
I've been testing with the Expiration Courtesy Notices.
event def 110
Hook au.expired (or expired on early setups)
repeat_delay 300 days
This should fire off if there no no 110 events in the last 300 days, and there isn't.
However, there is a single event from 3 months ago for a different trigger,
event def 32
hook biblio.format.record_entry.print
So it looks like Evergreen needs to not just find events with a matching target, but also limit them to the event definition as well.
It looks like it only cares about the target value,
open-ils.cstore.direct.actor.user.id_list.atomic [{"active":"t","home_ou":{"in":{"from":"aou","where":{"id":2},"select":{"aou":[{"transform":"actor.org_unit_descendants","result_field":"id","column":"id"}]}}},"deleted":"f","-and":[{"+atev":{"id":null}}],"expire_date":{"between":["2019-03-06 10:05:03+0000","2019-04-05 10:05:03+0000"]}},{"join":{"atev":{"filter":{"start_time":{">":"2018-05-09 10:05:03+0000"}},"fkey":"id","field":"target","type":"left"}}}]
This turns out to be a very straight-forward fix. Branch here:
https:/
From the commit message:
This bug has existed since the repeat_delay feature was added, but likely only rarely was triggered because most events don't have a repeat_delay, and those that do don't interact with the same target. However, as more repeatable event definitions are created, inappropriate interaction becomes more likely.
In this commit we avoid overwriting the whole join condition clause, which already contains an event definition id filter and needs to retain it.
Included is an unrelated change that uses the new-ish form of interval_to_seconds that avoids DST boundary shifting issues by passing a context DateTime object as the second parameter.