The event names 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, and profiles could be added.
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.
The column difference indicates if a Difference is included for events of this type or subtype.
Family | Name | Legacy Name | Since | Metadata Update | Diff | Description |
---|---|---|---|---|---|---|
|
|
| Transcode job is created | |||
|
|
| Transcode job is finished | |||
|
|
| Retranscode job is created | |||
|
|
| Export job is created | |||
|
|
| Export job is finished | |||
|
|
|
| File has successfully acquired the | ||
|
|
| SIP was resubmitted while it is already archived based on the ExternalId | |||
|
|
| SIP was resubmitted while it is already processing based on the ExternalId | |||
|
|
| ||||
|
|
| Because the MD5 was unknown when creating the record (when using | |||
|
|
| Record is created | |||
|
|
| Metadata of record is updated | |||
|
|
|
| Record has been published from the ingest space or auto-published | ||
|
|
|
| Record has followed its Destruction to its end | ||
|
|
|
| Technical metadata has been extracted | ||
|
|
|
|
| Technical metadata and preview path are updated when the transcoding completes | |
|
|
| The ingest of the record is now fully completed and now has record status | |||
|
|
| The record has been permanently rejected | |||
|
|
|
|
| Record is logically deleted | |
|
|
|
|
| Logically deletion of record is undone | |
|
|
| Record is permanently deleted and this delete can no longer be undone, all storage is reclaimed shortly afterwards | |||
|
|
| Virus check is performed | |||
|
|
| MD5 generated from file is compared with the reference | |||
|
|
| Fixity of the file will be checked by exporting it | |||
|
|
| Fixity check is finished | |||
|
|
| Generated when a Direct Downloads is done for the original (representation) | |||
|
|
| Generated when a Direct Downloads is done for the access representation or browse |
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