not_log table is really big in several environments. What is stored in this table and how do we maintain it?

Document ID : KB000044074
Last Modified Date : 14/02/2018
Show Technical Document Details

Size of the MDB Database not_log is really big.  Some installations could have table sizes around 10 GB.
What is stored in this table and how do we maintain it?

In Service Desk Manager, log_all_notify  is a feature is set to yes by default by the installer of Service Desk.

1/ Documentation of this feature
Logs all notifications, regardless of the method used. Logging a notification creates a notification log object that records the recipient, date/time, method of notification, and the notification text.

The administrator uses the Notification History list to view and maintain notification log objects. The notification history can also be viewed from an individual ticket.

If this option is not installed, the contact receives only the notification specified in the Contact record. No record is kept of the notification attempt.

2/ Configure this functionality
Administration TAB -> "Option manager"
We could set via the right pane
log_all_notification variable to yes or no
conf noti.png 

3/ Web Application based on not_log table
Service Desk TAB -> view -> Notification History
We could have a direct access to notifications without going to each incidents
notif his.png 

4/ Maintain not_log table
Purge of an incident will also delete the record in act_log relative to the incident to purge, but records in not_log are not child object of any incident or request, etc...

We have to purge the not_log table via a rule.
Create the rule on "notify log header" object.
The purge will delete records based on the "day inactive" field of the purge rule.

"day inactive" of the rule is the last_mod column in not_log table

The purge will not check if the notification to be purged in not_log belong to an active or inactive incident. It will purge only per the last_mod of not_log date greater than the "day inactive" of the rule.