How does version management work

Version management enables tracking and maintaining different versions of an asset through a structured process. This functionality relies on Workcopy Management, which supports creating, editing, and publishing versions of assets.

Required Properties for Version Management

For an asset to be compatible with version management, its structure must have the following properties:

• copietravail (Workcopy Reference):

  • Type: Child object reference.

  • Description: Contains the reference to the current published asset this workcopy is meant to replace. It should be always populated for workcopies.

• uid (Unique Identifier):

  • Type: Text field (objectname_id, where objectname is the asset type and id is the asset’s unique identifier).

  • Description: Links all versions of an asset, enabling the system to track related instances.

• version (Version Number):

  • Type: Integer.

  • Description: Indicates the version number of the asset.

Version Management Workflow

The lifecycle of the creation of a new asset version follows several key stages:

1. Published Asset (Current Version):

   • An asset is considered to be the current version if its status is the one considered online. For example, Published is the online status of the default delivered workflow for assets (wkfasset).

2. Workcopy Creation (Draft Version):
   When creating a new version, we do the following :

   • A workcopy of the published asset is created.

   • It inherits all metadata from the published asset but is assigned a new ID and the default status of the structure (Draft for the default workflow of assets).

   • The copietravail property references the published asset.

3. Editing the Workcopy:

   • The workcopy can be edited, saving changes without affecting the published version.

4. Publishing the Workcopy:
   When the workcopy is ready to become the new current version, it is published. It triggers the following modifications

   • The system archives the previously published asset and stores it in a new instance with the status marked as archived.

   • The workcopy becomes the new published asset with the same ID as the original asset.

   • The workcopy instance is deleted at this point

Example Scenario:

We have an asset with:

• ID: 23

• Status: Published

• Version: 1

1. Creating a Workcopy

• A workcopy is created to edit the asset.

• The new asset instance will have the following:

  • ID: 24

  • Status: Draft (or the default initial status defined in wkfasset)

  • The same property values as the current asset.

  • copietravail: Points to the current version (23).

  • uid: asset_23

2. Publishing the Workcopy

• After editing, the workcopy can be published.

• Publishing triggers a workflow transition from Draft to Online.

3. Post-Publication Changes

• The current asset (23) is archived with a new ID (26).

• The workcopy (24) becomes the new published version with ID 23.

• The workcopy instance is deleted.

Illustration

Here’s a sequence diagram illustrating this workflow:

@startuml
title Asset Version Management - Example Workflow

actor User as U
participant "Asset (ID: 23, Version: 1)" as A23
participant "Workcopy (ID: 24, Version: 2)" as W24
participant "System" as S
participant "Archived Asset (ID: 26)" as A26

U -> A23 : Request Workcopy Creation
A23 -> S : Send Metadata (UID: AssetType_23, Version: 1, Status: Published)
S -> W24 : Create Workcopy (ID: 24, Status: Draft)
W24 -> W24 : Copy Metadata from Asset 23
W24 -> A23 : Reference Asset 23 (copietravail)
U <-- W24 : Workcopy Created (ID: 24, Version: 2)

U -> W24 : Edit Workcopy
W24 -> S : Save Changes

U -> W24 : Publish Workcopy
W24 -> S : Request Publish
S -> A23 : Archive Asset 23
A23 -> A26 : Archive Created (ID: 26, Status: Archived)
S -> A23 : Replace with Workcopy ID: 24
destroy W24

U <-- A23 : Asset Updated (ID: 23, Version: 2, Status: Published)

@enduml