Events

Structure

The event name are structured in three parts

CONCEPT.TYPE.SUB-TYPE

Example

RECORDS.UPDATE.PUBLISH

Currently the only available concept is “RECORDS”; in the future other concepts such as users, profiles could be added.

API versus Monitoring

In the MediaHaven Monitoring the events are shown using the “Legacy Name” while in the MediaHaven REST API it is always shown using the fully qualified name.

Overview

The column difference indicates if a Difference is included for events of this type or subtype.

Family	Name	Legacy Name	Since	Description
`FLOW`	`RECORDS.FLOW.TRANSCODE`	`TRANSCODE`		Transcode job is created
`FLOW`	`RECORDS.FLOW.TRANSCODED`	`TRANSCODED`		Transcode job is finished
`FLOW`	`RECORDS.FLOW.RETRANSCODE`	`RETRANSCODE`		Retranscode job is created
`FLOW`	`RECORDS.FLOW.EXPORT`	`EXPORT`		Export job is created
`FLOW`	`RECORDS.FLOW.EXPORTED`	`EXPORTED`		Export job is finished
`FLOW`	`RECORDS.FLOW.ARCHIVED`	`ARCHIVED`		File has successfully acquired the `Administative.ArchiveStatus` `on_disk` or `on_tape`
`FLOW`	`RECORDS.FLOW.SIP_ALREADY_ARCHIVED`	`SIP_ALREADY_ARCHIVED`		SIP was resubmitted while it is already archived based on the ExternalId
`FLOW`	`RECORDS.FLOW.SIP_ALREADY_PROCESSING`	`SIP_ALREADY_PROCESSING`		SIP was resubmitted while it is already processing based on the ExternalId
`FLOW`	`RECORDS.FLOW.SIP_DETECTED`	`SIP_DETECTED`
`FLOW`	`RECORDS.FLOW.DUPLICATE_MD5_DELETE_POOLS`		`23.3`	Because the MD5 was unknown when creating the record (when using `ExternalSourceUrl`), the MD5 duplicate is only detected after downloading the URL. To prevent using unneeded storage, the original storage is immediately reclaimed.
`CREATE`	`RECORDS.CREATE`	`CREATE`		Record is created
`UPDATE`	`RECORDS.UPDATE`	`UPDATE`		Metadata of record is updated
`UPDATE`	`RECORDS.UPDATE.PUBLISH`	`PUBLISH`		Record has been published from the ingest space or auto-published
`UPDATE`	`RECORDS.UPDATE.TRANSCODED`		`24.1`	Technical metadata and preview path are updated when the transcoding completes
`DELETE`	`RECORDS.DELETE`	`DELETE`		Record is logically deleted
`DELETE`	`RECORDS.DELETE.UNDELETE`	`UNDELETE`		Logically deletion of record is undone
`DELETE`	`RECORDS.DELETE.PERMANENTLY_DELETED`		`21.2`	Record is permanently deleted and this delete can no longer be undone, all storage is reclaimed shortly afterwards
`VALIDATION`	`RECORDS.VALIDATION.VIRUS_CHECK`	`VIRUS_CHECK`		Virus check is performed
`VALIDATION`	`RECORDS.VALIDATION.MD5_CHECK`	`MD5_CHECK`		MD5 generated from file is compared with the reference
`VALIDATION`	`RECORDS.VALIDATION.VERIFY`	`VERIFY`		Fixity of the file will be checked by exporting it
`VALIDATION`	`RECORDS.VALIDATION.VERIFIED`	`VERIFIED`		Fixity check is finished
`DIRECT_DOWNLOAD`	`RECORDS.DIRECT_DOWNLOAD.ORIGINAL`		`22.4`	Generated when a Direct Downloads is done for the original (representation)
`DIRECT_DOWNLOAD`	`RECORDS.DIRECT_DOWNLOAD.ACCESS`		`22.4`	Generated when a Direct Downloads is done for the access representation or browse

Metadata Update

The column “Metadata Update” indicates that, when true, this event will also cause the record to be updated in the index and the metadata field Administrative.LastModifiedDate to be changed accordingly → Metadata 21.1
The timestamp of the event and Administrative.LastModifiedDate can have the exact same value or differ on the order of milliseconds.
The field Administrative.LastModifiedDate is changed for the record and all its fragments when the metadata is updated
- When in case of an update only Descriptive or Dynamic fields are changed, then only that particular fragment is updated instead
- When changing metadata fields outside the families Descriptive and Dynamic, e.g. when publishing the fragment (family Administrative) or changing the permissions (family RightsManagement), then the record and all its fragments are updated
- See Metadata Families for information about the different families