Comment 2 for bug 1124498

There could be a possible flaw in this setup. The action triggers rely on event targets to make sure they don't duplicate themselves. Example, overdue notices use circ ID's for it's target. Password requests use the ID from the actor.usr_password_reset table. My concern is that this expire notice is using the target ID of the actor.usr table in which will never change for the lifetime of the patron. I believe that once a notice event is created, a year from now when that patron is up for expiration once again, the system will see that it already had sent a notice for that patron on that event and it will never send another one even if it's a year later and a different expiration period.

Steve