...
| Page Properties | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||
Resources & Remarks article is too brief and not fitting the intended structure. Topic should actually link to SOTs, link to the endpoints for changing storage, and link to a tutorial outlining the usage. Modification History
|
| Excerpt |
|---|
A retention can be used to ensure that a document object is not deleted and the binary content file assigned it is not deleted or changed. |
...
Since the retention is stored within the objects' metadata, the individual values can be retrieved like other object properties, e.g., via the GET /api/dms/objects/{objectId} endpoint. It is not possible to define retention periods for objects without the system:rmDestructionRetention.
| Note | ||
|---|---|---|
|
...
The retention defined in the SOT protects binary content files from beeing modified/deleted via yuuvis® Momentum API. However, objects under retention can still be modified/deleted by administrators having direct access to the used storage. To prohibit such administrative operations, some archives offer an archive-internal retention as well. In those archives, the retention specified in the individual objects' metadata is set as an individual archive-internal retention. |
| Note | ||
|---|---|---|
| ||
| The metadata of objects under retention are NOT protected from changes. They remain editable. If you want to prohibit metadata updates in project-specific use cases, you can configure a suitable webhook, that is triggered before the process you want to prohibit. |
'system:rmDestructionRetention' SOT
...
| Property | Type | Description |
|---|---|---|
| datetime | Required to set a retention. Specifies the date until which the document object will be unter retention. The value must not lie in the past at the time of specification. If the value is If not specified, the default retention of the used repository will be set if defined in the corresponding archive profile. The default retention does NOT replace a retention specified via API, even if the default retention would result in a later expiration date. |
system:rmStartOfRetention | datetime | Optional. Not considered or validated by yuuvis® Momentum core system. Can be used to specify the start date of the retention period for documentation purposes. |
system:rmDestructionDate | datetime | Optional. Has to equal or exceed the value for Can be used to specify a date to trigger an automated deletion via a custom service. The yuuvis® Momentum core system does not yet offer an endpoint for this purpose. |
...
It is possible to extend the functionality of yuuvis® Momentum by configuring Webhooks webhooks and adding custom microservices. Thus, you can build your own specialized solution to realize automated retention management.
You could automatically One possible use case would be to calculate the required retention values based on the individual object's metadata and set them, e.g.,
- during the object creation,
- during a specific update of the object's metadata, or
- triggered by a specific metadata update of the parent folder object (if you use
system:parentId).
For the deletion of document objects with expired retention, you can introduce automated custom solutions as well. E.g., you could build with a custom microservice in your system that automatically searches for objects with expired retention and
- deletes them,
- updates their state in the lifecycle via Tagging tagging, or
- starts a workflow process asking responsable assigned users to delete them (if BPM-ENGINE Service is used).
...