What I am seeing is that due to the au.created hook automatically firing off in the "update_patron" routine in OpenILS/Application/Actor.pm, that the delay on the trigger is completely ignored and a notice is created no matter what with no regard to the delay setting (the notice is created with a run_time as now() ). I believe it's because the trigger is marked as "passive".
So the quick fix here, and what I beleive is the correct thing to do, is to just change the trigger from passive to not in the database.
update action_trigger.hook set passive =false where key='au.created';
The catch here however, is that if folks have been relying on a "passive" trigger to go out and create notices after their repeat_delay threshold, it will no longer do that since it will rely on creating the notice at new user time, rather than going out and finding existing ones.
What I am seeing is that due to the au.created hook automatically firing off in the "update_patron" routine in OpenILS/ Application/ Actor.pm, that the delay on the trigger is completely ignored and a notice is created no matter what with no regard to the delay setting (the notice is created with a run_time as now() ). I believe it's because the trigger is marked as "passive".
So the quick fix here, and what I beleive is the correct thing to do, is to just change the trigger from passive to not in the database.
update action_trigger.hook set passive =false where key='au.created';
The catch here however, is that if folks have been relying on a "passive" trigger to go out and create notices after their repeat_delay threshold, it will no longer do that since it will rely on creating the notice at new user time, rather than going out and finding existing ones.