* Sends an email with subject line "Item is in the New state" * Repeats every 1 minute until the item is no long in the New state (The repeat is not necessary but makes it easier to see the problem.) * Has an escalation rule that sends an email with subject line "Item has been in New state too long", that starts after 5 minutes.
An escalation may run multiple times instead of just once if the escalation has a rule associated with it and the "Attempt to send all notifications for an item" option is checked on the Performance tab of the Configurator in SBM 10.1.1.4. To work around the issue, the "Attempt to send all notifications for an item" option should be unchecked in the Configurator or the "ns-default-config.xml"
This immediately caused warnings to be generated that the notification server was trying to process entries in the TS_NotificationEvents table that didn't have an associated Notification. Even though the notification had been deleted, users were still receiving emails. These were associated with escalations / repeats .
If the email is set to repeat (e.g., email every day until owner changes) or to escalate (e.g., email in seven days if the item hasn't been updated) then the event will not be deleted after the initial send: the system will hang on to the event record and will create another email when that repeat or escalation time period is reached
If the e-mail is set to repeat (e.g., e-mail every day until owner changes) or to escalate (e.g., e-mail in seven days if the item hasn't been updated) then the event will not be deleted after the initial send: the system preserves the event record and creates another e-mail when that repeat or escalation time period is reached.
Notification history appears to have duplicate recipient entries for repeat or escalated notifications . The notification date and time is shown with a list of recipients that is duplicated.
