Requirements
Structure
It is possible to use the version management feature only on assets that have a workcopy-compliant structure. A structure is workcopy compliant if it has the following properties :
Property | Type | Description |
|---|---|---|
| Child -> #self | References the current version of the asset to be replaced. |
| Text | Unique identifier in the format This field is empty for current versions that haven’t been replaced by another version yet. |
| Integer | Indicates the version number. |
These properties are verified in the Wizards tab of the object structure administration interface.
For the need to identify archived versions, a new property has been added to the assets' structure :
versionsdata :
Type : word
Description : Store data related to versions (Eg: Archivage reason of a version:
obsolete)
Arounf the tab “Versions”
Configuration
The version management feature is accessible on the front end via the tab Versions on the detail page.
To configure the display of that tab, the following entry point can be used: $.common.namedDisplays.defaultAssetDetailTabVersions. This tab configuration has been added to the configuration of the tabs on the stater-kit configuration delivered by default via this entry point $.common.namedDisplays.defaultAssetDetailMeta.column.tabs.
Security
Under the security property of the tab configuration(defaultAssetDetailTabVersions.security), it is possible to define which security domain(s) should be evaluated to display the versions tab.
By default, it is preconfigured with :
["objectdata/insert"]
This means that the “Versions” tab is by default displayed to users allowed to create instances in the instance’s object visualized on the detail page.
It is possible to use the following security domains :
objectdata/insert
objectactions/create
objectactions/multiupdate
objectactions/delete
objectactions/view
objectactions/changestatus
If the security domains configured are multiple, all security domains should be granted for the user to see the versions tab.
Actions on versions
A set of actions is possible depending on the type of versions and permissions of the user.
Draft version :
Preview and edit: Only if the user is allowed to edit the instance
Delete: Only if the user is allowed to delete the instance
Publish: The publish action of a draft version is accessible from the previsualization interface. This action is enabled only if the user has permission to execute a workflow action that can take the instance to an online status.
Archived version :
Preview: Works if the user is allowed to edit the instance.
Delete: Only if the user is allowed to delete the instance
Restore: It’s possible to restore an archived version and make it become the current one. This action is displayed only if the user has the right to process an action that can take the asset from the archived status to an online status.
Current version: No actions are available on the versions tab. Actions for the current instance are displayed on the header.
Versions are still assets, and thus, they are evaluated through security the same way as assets not involved in version management (through their status, for instance).
Identification of versions
It might be useful to be able to distinguish in certain circumstances (security, basewhere evaluations, etc) the different types of versions. You can use the following table to do so
Version type | Description | Characteristics |
|---|---|---|
Current version (Published/Online) | It represents the current version of an asset. |
|
Draft version (Workcopy) | It's the initial state of the new version of a published asset. It has the same values as the asset that it has been created from except status, uid, copietravail and version. |
|
Archived version | It represents versions that were the current or active ones at a certain point in time and were replaced by a draft version. They are now considered as obsolete. |
|
Miscellaneous
New tag pkg/versions/keep/on/publish
A new tag pkg/versions/keep/on/publish has been introduced to be able to identify fields on assets structure that need to be kept and not overridden or changed when instances are replaced by new versions.
It is by default assigned to the portals field.
For example, let’s consider an asset X (current version) that has been assigned to sections A and B of portal 1. If we create a new draft version of X, the field portals of the draft version still have the same references: A and B of portal 1, as it has been copied from the asset X.
While the work is in progress on the draft version, asset X is now assigned to a new section C So now asset X is assigned to sections A, B, and C.
That work doesn’t affect the draft version or workcopy, which at this point, only holds the references of sections A and B.
The tag pkg/versions/keep/on/publish prevents the deletion of reference C from being deleted after the publication of the draft version when it will replace the active version.
To sum up, this tag is used to identify properties that we don’t want to change when the current version is replaced by the draft version. It can be added to other properties that will work on the same principle as portals.
Filtering of archived versions on the front end
Archived versions are not displayed on the front end by default. They are masked via a service of the plugin PACKAGED_Versions and are filtered by default when requesting the following types of API endpoints :
"ASSET", // Eg: api/rest/dam/asset "SEARCH", // Eg: api/rest/dam/data/asset, "TOPSEARCH",//Eg: api/rest/dam/data/asset1,asset2 "ASSET_AGGS", //Eg: api/rest/dam/asset/aggs, "MULTI_AGGS" //Eg: api/rest/dam/data/aggs/asset1,asset2
You can extend the APIBaseWhereBusinessServiceAdapter (using the field versionsdata) inside a project plugin if you want to filter additional endpoint types on the front end or submit an amelioration ticket on the product if you find it useful to restrict more endpoints by default.