Persistence of attribute values

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.