Deletion Monitor [VF 22.1 UG]

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.

Database

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 Elastic index “deletion-monitor“. It is highly recommended to backup the SQL database regularly.

The replication of Deletion Monitor data from from SQL to Elastic can be triggered manually via API call.

User interface

There is no UI provided by VidiFlow. The intention is use Kibana on the Elastic index. The following screenshot show an example UI:

Users can also create dashboards in Kibana to monitor deletion activity. This screenshot shows an example how this could look like:

Detailed information

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

Limitations

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 Elastic databases, meaning the databases will always grow in the current implementation.