Events
Structure
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 → https://mediahaven.atlassian.net/wiki/spaces/CS/pages/4400775176.
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 | 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 |
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.1The 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 updatedWhen in case of an update only
Descriptive
orDynamic
fields are changed, then only that particular fragment is updated insteadWhen changing metadata fields outside the families
Descriptive
andDynamic
, e.g. when publishing the fragment (familyAdministrative
) or changing the permissions (familyRightsManagement
), then the record and all its fragments are updatedSee Metadata Families for information about the different families