Expiration Rules are used to determine the objects life time.

After the desired time all the objects referencing an expiration rule will get the specified spikeCode or an expiration workflow will be applied to them.

An expiration rule can be referenced only by a partition. All the objects referencing that partition will reference also the expiration rule.

An expiration rule contains the following properties:

Name

The name of the expiration rule

expirationComputedTrigger

Determine how the expiration date is calculated for the objects referencing it.

Possible values:

•whenCreated : the expiration date will be calculated from the object creation date

•whenModified: the expiration date will be calculated from the object modified date

•attribute: the expiration date will be calculated from an object attribute

AttributeName

Makes sense only if the expirationComputedTrigger is set to "attribute", determine which attribute will be used to calculate the expiration date.

expirationTimeSpan

The number of days that will be added to the creation/modified date to calculate the expiration date.

objectTypes

A list of object types (space-separated). Determine which object types will be affected by the rule. An empty value means "all object types"

spikeCode

The delete code to use to delete the objects when they expire

spikeUnref

Unref parameter used when deleting objects. Example: if you want to unpublish stories when deleting them, put pubDest.objs in this field.

spikeExtend

Extend parameter used when deleting objects. Warning: all objects you put in this field will be deleted! Example: if you want to delete stories published on a pudDest and put pubDest.objs in this field, also the publishing destination will be deleted.

purgeTimeSpan

The purge time

workflowName

The name of the workflow to launch when the objects expire

workflowPars

Additional parameters to pass to the workflow (name-value)

Notes

•You cannot specify both spikeCode and workflowName (in this case only the workflow would be executed).

•It's better to always specify one (or more) object type for an expiration rule to avoid errors (Ex. you reference the wrong expiration rule on a partition affecting the wrong objects)