-
Notifications
You must be signed in to change notification settings - Fork 16
Action – Version
Eric Domke edited this page May 6, 2019
·
1 revision
<!-- SOAP_ACTION = ApplyAML or ApplyItem -->
<Item action='version'>
</Item>
For automatically-versioning items, merely edit the item to trigger a version
Event | Context | Notes |
---|---|---|
onBeforeVersion | <Item action='version' id='OLD' loadedPartialy="0" isDirty="1" LastModifiedOn="1389988191000" doGetItem="1" version_do_unlock="0"> <property>new user values</property> </Item> |
Context = old version metadata with new version user data |
onAfterVersion | <Item action='version' id='OLD'> <property>new user values</property> </Item> |
Context = old version |
- With
onBeforeVersion
, you can change the unlock behavior by setting theversion_do_unlock
attribute to a different value. - Properties stored on the context item in the
onBeforeVersion
method will be persisted after theonAfterVersion
method. Modifications to the context item inonAfterVersion
appear to be ignored and SQL updates made during this method are overwritten.
-
Automatic: A new generation is created after the first save in every edit cycle (lock-save-unlock).
- Default Behavior: New generations are not created after each subsequent save if the item stays locked. Aras tracks this by setting the new_version field to one on the first save. That way, subsequent saves know not to create a new version.
(:no_entry: Version 9.3)Keep Version Item
Checked on Life Cycle State: New generations are created after each subsequent save regardless of it the item stays locked.
- Manual: A new generation is only created when specifically requested.
-
Floating relationship behavior
- Versioning the child item causes the relationship item to be modified in the database so that the
related_id
property points to the current generation of the child item. The modified metadata (e.g.modified_on
) of the relationship item is not altered. - Versioning the parent item causes all of the relationship items to be copied.
- Versioning the child item causes the relationship item to be modified in the database so that the
-
Fixed relationship behavior
- Versioning the child item has no immediate impact on the parent.
- Versioning the parent item (even if it is not released) causes all of the relationship items to be copied. These new relationships point to the current generation of the child item.
-
Hard fixed/float
- Hard fixed/float is used to force a fixed or float behavior regardless of life cycle state.
- When the relationship item has a life cycle, versioning the parent item causes a new relationship item to be created with the starting life cycle state regardless of the life cycle state of the original relationship item.
- When a new generation is created for an item in a released state, its major revision is incremented and the life cycle state is set back to the original start state.
- When a non-versionable item in a released state is edited, its life cycle state is set back to the original start state.
- For baselining to function, the parent item must be in a life cycle state that has the Version Relationships on Property Float option selected. (This will automatically select the other three options.) In addition, the parent item must be released, the relationship must be set to float, and the relationship item cannot have anything that might interfere with versioning (e.g. a life cycle). If these criteria are met, then versioning a child item (regardless of the child item's released status) will create a new generation of the relationship.
- Relationship Items with baseline versioning can be versioned using the version action in AML.
-
Keep Version Item: A new generation of versionable item will be created on every "do version" event. Not applicable to Manual versioning discipline.
- Example: If the setting is enabled and Automatic versioning discipline is specified on the ItemType this will result in versioning on every save of an instance while the instance is in such Life Cycle State.
-
Keep Version Relationships: A new generation of versionable relationship will be created on every "do version" event. Not applicable to Manual versioning discipline.
- Example: If Automatic versioning discipline is specified on a RelationshipType this will result in versioning on every save of a relationship while it's source item is in such Life Cycle State.
-
Version Item on Property Float: A new generation of versionable item will be created when property of the item automaticaly 'floats' to point to the newest generation of some versionable item. Not applicable to Manual versioning discipline.
- Example: If one has a versionable ItemType 'A' that has a property 'p' pointing to a versionable ItemType 'B' and behavior on property p is 'float' then versioning of instances of type 'B' will cause versioning of pointing to them instances of type 'A' that are in such Life Cycle State.
-
Version Relationships on Property Float: A new generation of versionable relationship will be created when property of the relationship automaticaly 'floats' to the newest generation of some versionable item. Not applicable to Manual versioning discipline.
- Example: If versionable relationship 'R' with Baseline versioning discipline and related_id property points to a versionable item 'B' then versioning of 'B' will cause versioning of 'R' when behaviour on relationships is float and source item is in such Life Cycle State.