...
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
| ||
| Integer | Indicates the version number. |
| Info |
|---|
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”
...
| Code Block | ||
|---|---|---|
| ||
["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 :
...
If the security domains configured are multiple, all security domains should be granted for the user to be able to see the versions tab.
Actions on versions
...
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.
| Note |
|---|
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.
...
Restoration of an archived version
...
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 :
| Info | ||
|---|---|---|
|
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.