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 | Update? | Diff | Description |
|---|---|---|---|---|---|---|
|
|
|
|
|
| The transcode job is created |
|
|
|
|
|
| The transcode job is finished |
|
|
|
|
|
| The retranscode job is created |
|
|
|
|
|
| Custom keyframe job is created |
|
|
|
|
|
| The export job is created |
|
|
|
|
|
| The 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 |
|
|
|
|
|
| Legacy event for ingest 1.0 https://mediahaven.atlassian.net/wiki/spaces/CS/pages/3262971922 that detected Complex Objects 1.0 |
|
|
|
|
|
| The SIP’s intellectual and data objects have been created |
|
|
|
|
|
| The SIP’s files have been extracted |
|
|
|
|
|
| Because the MD5 was unknown when creating the record (when using |
|
|
|
|
|
| File copied to destination pool(s) |
|
|
|
|
|
| File moved to destination pool(s) |
|
|
|
|
|
| Indicates that a resumable file upload has been completed |
|
|
|
|
|
| File moved to storage of other tenant |
|
|
|
|
| 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 process for the record is fully complete. The record now has a status of | ||
|
|
|
| The record has been permanently rejected | ||
|
|
|
| Contains the updates to the non-descriptive and non-dynamic fields that are shared with all pure fragments --> Fragments. | ||
|
|
|
|
|
| This event is added on an original representation when the version status changes to head. See Data Version Management for details. |
|
|
|
|
|
| This event is added on an original representation when the version status changes to tail. See Data Version Management for details. |
|
|
|
|
|
| This event is added on a data object when a new version of the original representation is created See Data Version Management for details. |
|
|
|
|
|
| This event is added on a data object when a new version of the original representation is rejected. See Data Version Management for details. |
|
|
|
|
|
| Enable versioning for original representation when uploading a new original. |
|
|
|
|
|
| MD5 validation check is performed on the record. |
|
|
|
|
|
| AI embeddings are regenerated on the record via a batch process. |
|
|
|
|
|
| Generated AI metadata is saved (embeddings, generative metadata, detected faces, …) |
|
|
|
|
|
| Record is archived |
|
|
|
|
|
| One or more detected faces were automatically linked to persons (requires module Facial recognition using DeepFace). |
|
|
|
|
|
| Person linked to face has been renamed. (requires module Facial recognition using DeepFace). |
|
|
|
|
|
| Person is assigned to face (requires module Facial recognition using DeepFace). |
|
|
|
|
|
| Person is unassigned from face (requires module Facial recognition using DeepFace). |
|
|
|
|
|
| Person linked to face has been removed (requires module Facial recognition using DeepFace). |
|
|
|
|
|
| Face on record has been removed (requires module Facial recognition using DeepFace). |
|
|
|
|
|
| Object has been migrated to another tenant. |
|
|
|
|
|
| Record is logically deleted |
|
|
|
|
|
| Logically deletion of record is undone |
|
|