Page Navigation

• Publish Trigger
• Preserve Current User Trigger
• Assign To Group Owning Asset Trigger
• Assign Step If User Trigger
• Assign to Specified Group Trigger
• Assign To Workflow Owner Trigger
• Email Trigger
• Version Trigger
• Merge Trigger
• Publish Set Trigger
• Delete Trigger
• Unpublish and Delete Trigger
• Create New Workflow Trigger
• Publish Parent Folder Trigger
• Delete Parent Trigger
• Copy Folder Trigger
• Publish Containing Publish Set Trigger

Most Read

• Web Services
• Code Sections
• Available Workflow Triggers
• Cascade Server CMS Primer
• Cascade Server CMS Primer Advanced
• Available System Tags
• System View Tags
• Available Plug-ins
• Authentication
• Data Definition Schema Reference

• Cascade Server 7.0 Beta 2 Release Notes
• Cascade Server 6.10.9 Release Notes
• Cascade Server 6.10.8 Release Notes
• Cascade Server 7.0 Beta Release Notes
• Cascade Server 6.10.7 Release Notes
• Cascade Server 6.10.6 Release Notes
• Cascade Server 6.10.5 Release Notes
• Cascade Server 6.10.4 Release Notes
• Cascade Server 6.10.3 Release Notes
• Cascade Server 6.10.2 Release Notes

Unpublish and Delete Trigger

Often, within the context of a workflow process, there is a need to un-publish an asset before removing it from the system.

The DeleteAndUnpublish trigger can be used in place of the previous Delete trigger. When the asset in the workflow is not a publishable asset (template, symlink, stylesheet, block, reference), this new trigger performs a standard delete. However, when the asset is a "publishable" asset (file, page, folder) and has publishable destinations, the trigger attempts to un-publish the asset (and all child assets if it's a folder) from all destinations prior to removing it from the system.

Implementation

Declaration

<trigger class="com.cms.workflow.function.DeleteAndUnpublish" name="DeleteAndUnpublish"/>

Usage

<trigger name="DeleteAndUnpublish"/>

Parameters

There are two parameters that can be set when calling the trigger on an action: authorizing-user and authorizing-type.

Authorizing-Type Parameter

The authorizing-type parameter is set when calling the trigger on an action. The authorizing-type parameter is used in any trigger that executes to a publish and is used to specify which user is "authorizing" the publish in this step. This will affect permissions/roles checks performed during publish and also to whom the publish report is delivered to. The "system" user is basically a way to bypass any permissions/roles checks but results in the publish report not being sent to anyone.

If authorizing-type is not set, the default value will be workflow owner (the user that started the workflow).

**Note - the Unpublish and Delete trigger cannot use the "system" user options, as the trigger requires a real username to be used to authorize deletion that occurs before unpublish.

Authorizing-type can take a value of "current-step-owner," "system," or "user."

• current-step-owner - the user assigned to the step that calls the trigger
• user - a specified user

Authorizing-User Parameter

This parameter is used if 'user' is selected as the authorizing-type (in the parameter above). This parameter value can be any valid user name.

**Note - Authorizing-user will only be used if the authorizing-type parameter is set to the value of "user," rather than "current-step-owner."

If you were to use both the "authorizing-type" and "authorizing-user" parameters, your xml would look like this:

<trigger name="DeleteAndUnpublish"> <parameter> <name>authorizing-type</name> <value>user</value> </parameter> <parameter> <name>authorizing-user</name> <value>johndoe</value> </parameter> </trigger>

The following is the default Delete workflow distributed with the software with the DeleteAndUnpublish trigger used in place of the Delete trigger.

<system-workflow-definition initial-step="initialize" name="1 Step - Delete and Unpublish"> <!-- triggers that will be available to actions in the workflow --> <triggers> <trigger class="com.cms.workflow.function.EmailProvider" name="email"/> <trigger class="com.cms.workflow.function.Publisher" name="publish"/> <trigger class="com.cms.workflow.function.DeleteAndUnpublish" name="DeleteAndUnpublish"/> </triggers> <!-- steps that should happen in order --> <steps> <step identifier="initialize" label="Initialization" type="system"> <actions> <action identifier="initialize" move="forward" type="auto"> <trigger name="email"/> </action> </actions> </step> <step default-who="admin" identifier="final-review" label="Final Review (user)" restrict-to-type="role" restrict-to-value="Publisher" type="transition"> <actions> <action identifier="reject-to-edit" label="Cancel" next-id="canceled"> <trigger name="email"/> </action> <action identifier="approve" label="Approve" move="forward"> <trigger name="email"/> </action> </actions> </step> <step identifier="finalize-delete" label="Deleting" type="system"> <actions> <action identifier="finalize" move="forward" type="auto"> <trigger name="DeleteAndUnpublish"> <parameter> <name>authorizing-type</name> <value>user</value> </parameter> <parameter> <name>authorizing-user</name> <value>johndoe</value> </parameter> <trigger name="email"/> </action> </actions> </step> <step identifier="deleted" label="Deleted" type="system"> </step> </steps> <!-- non ordered steps --> <non-ordered-steps> <step identifier="canceled" label="Canceled" type="system"> </step> </non-ordered-steps> </system-workflow-definition>