System administrators or material managers from the customer side often want to determine when and why assets where deleted or will be deleted from the system’s housekeeping. The VidiFlow Deletion Monitor allows one to monitor information about deletion of items, collections and files. Additionally, different information about deletion locks are stored.
All information of the Deletion Monitor are based on receiving notifications from VidiCore. The Deletion Monitor catches those notifications and creates or updates data records in its own SQL database “VPMS_Platform_DelMonitor” and a corresponding OpenSearch index “deletion-monitor“. It is highly recommended to backup the SQL database regularly.
The replication of Deletion Monitor data from from SQL to OpenSearch can be triggered manually via API call.
There is no UI provided by VidiFlow. The intention is to use OpenSearch index. The following screenshot show an example UI:
Users can also create dashboards in OpenSearch Dashboard to monitor deletion activity.
In detail, the following information are stored by Deletion Monitor:
All deletion records for items, collections and files (lock creation, modification and deletion)
All deletion records for items, collections and files
Additional information (whenever possible):
Metadata for items and collections. The metadata to be stored are configurable.
Filename for files
Deletion locks also includes effective lock changed records
There are some known limitations:
The information (e.g. metadata title) are only able to be captured in certain scenarios, e.g. when a deletion lock is created or modified. It is not possible to retrieve it after the item was deleted.
It is mandatory to configure at least one metadata value.
A maximum of 10 metadata can be configured, with more than 10 values you get exceptions in the service.
Inherited locks are not shown by default. This is handled by using the effective locks changes to see the actual locks from inherited locks.
There is no deletion mechanism for the SQL and OpenSearch databases, meaning the databases will always grow in the current implementation.