Persistence of attribute values

The value of an attribute in a workflow may be persisted when its entry moves from one step to another in the workflow, or when the entry is finally checked in to its source container. Whether or not an attribute is persisted is controlled solely by whether it is set editable in the corresponding workflow step. Whether the attribute is in fact editable in the workflow step is also controlled by whether it is set editable in its entry’s spec. The combined effects of these settings is described here.

Specs

An attribute can be marked as editable in a spec (by checking the Editable check box, which is usually the default setting). If this check box is unchecked the attribute is read-only in any editor, so the user cannot change its value directly. However, a non-editable attribute's value may be changed by a script or Java™ API operation. The setting of the editable property in the spec has no effect on whether the attribute value is persisted in a workflow.

Workflow steps

When defining a workflow step, you can set the Attributes to validate by choosing to select one or more attribute collections. All the attributes in these collections are then validated when an entry moves from one step to another in a collaboration area. The three settings for attribute values within a workflow step are:

Viewable
Editable
Required (which also implies Editable)

This may be done independently for three different content authoring screens: Edit, Bulk Edit and Item Popup (or Category Popup). This means, for example, that the same attribute may be editable in Edit but not in Bulk Edit. These settings control whether an attribute is editable by the user (those marked Viewable may not be edited), but they also control the persistence of the attribute. When an entry is moved to another step or is checked in to its source container from a collaboration area, only those attributes that are Editable or Required are persisted. Attribute values marked as Viewable are not persisted.

If an entry is newly created in a workflow step (that is, it had not been checked out to that step or moved to that step from another step), all its attributes are persisted, even those attributes marked as Viewable.

These settings affect whether users can edit the attribute values within the UI. For editing, each setting applies independently for the different content authoring screens. However, for persistence the situation is different: if an attribute value is set as Required or Editable in any one of the content authoring screens, that setting defines that the attribute value is persisted.

Persistence to source container

Only Editable and Required attributes are persisted when an entry is checked into its source container. (Such attributes are often referred to as "checked out" attributes.) This is to ensure that if more than one user is working concurrently on the same entry in different collaboration areas these users do not overwrite one another's changes. To allow such concurrent access, you must define the editable attribute collections for the entry in different workflows or steps such that these collections contain disjoint sets of checked out attributes.

For example, say you want to allow the situation in which user A is working on item item1 in collabArea1, in which attributes a1 and a2 are checked out, while user B is simultaneously working on item item1 in collabArea2, in which attributes a3 and a4 are checked out. You need to define a different workflow for each collaboration area, so that the workflow for collabArea1 has a1 and a2 marked editable and a3 and a4 marked viewable, while the workflow for collabArea2 has attributes a3 and a4 marked editable and a1 and a2 marked viewable.

Another example is if an item was created in the collaboration area (and there is no source catalog item), all of the attributes from the collaboration area item are copied into the source catalog item. This can be an important difference, especially if not all of the item attributes were checked out to a collaboration area. If you automatically are setting values for attributes not checked out to the collaboration area (through value rules or default values, and so on...), those values are still getting set. The item now being created in the source catalog during the checkin process might contain undesired or unexpected attribute values, if not prevented by validation rules. Depending on the desired business logic you have to implement the corresponding logic in your PostProcessing script.

Examples

Example of a common use case: Those attributes that the user is expected to be able to change should be marked Editable in the spec and be given a Required or Editable setting in the step. Those that the user is not meant to change in the collaboration area step should also be marked Editable in the spec but be given a Viewable setting in the step.
Example with immutable attributes: Those attributes that no user (including an Admin) is expected to change by direct editing should be marked as non-editable in the spec. They are then non-editable in any situation, and the values are not persisted from a workflow.
Example with mutable but non-editable attributes: Suppose there are attributes that you do not want the user to edit directly in a workflow but whose values you may want to allow to be changed in the workflow by a script, for example, and persisted to the container. The way to do this is to mark such an attribute as non-editable in the spec but Editable (or Required) in the step. If the Admin wanted to change the value outside the step, this could be done only by use of a script.