Hide workflow statuses from specified groups

Within a workflow, you can control which groups see which workflow statuses.

About this task

By default, when you open the Change Status dialog box, all the available statuses to which an object can be set to are visible to all groups. Depending on the situation or the complexity of your workflow, you might want to limit the number of statuses visible to only those relevant to the group.

Important: Make configuration changes in a test environment and confirm they work before copying them to a production environment.

Suppose your workflow is similar to the diagram. If you have a topic with a Authoring:revDone status, and then you open the Change Status dialog box, your default choices are Authoring:edit, Authoring:review, and Authoring:work. You can hide the Authoring:edit status from users in the subject matter experts (SMEs) group, so they cannot push a topic to that status.

Figure: Example of a workflow for a topic
Example of a workflow

To restrict visibility of status options by group:

Procedure

  1. In the TEXTML Administration perspective, connect to your server.
  2. Expand the Content Store's Repository node and browse to /system/conf/ to locate the accessrights.xml file.
  3. Right-click accessrights.xml and click Check Out.
  4. Double-click the file to open it in the XML editor area.
  5. Locate the section that begins with: 
    <!-- ******* API METHODS DO NOT MODIFY ******* -->
  6. Copy the following template and paste it before that section. 
    <!-- ********************** STATUS CHANGE ********************* -->
<method name="[target status]" type="statuschange">
	<notify enabled="false"/>
	<conditionset operator="any">
		<condition>
			<current>
				<type name="[object]">
					<statuses>
						<status>[initial status]</status>
					</statuses>
				</type>
			</current>
			<users>
				<groups>
					<group name="[group]"/>
				</groups>
			</users>
		</condition>
	</conditionset>
</method>
  7. Edit the template to suit your needs.
    Note: Be careful to ensure that all groups still have the ability to move objects through the workflow appropriately. In other words, don't create any "dead ends."
    OptionDescription
    [target status]

    Replace [target status] with the status (the object's cycle and state) whose visibility you want restrict.

    As per the example, you would replace [target status] with Authoring:edit.

    <method name="Authoring:edit" type="statuschange">
    [object]

    Replace [object] with the type of object (topic, map, or image) to which the restriction applies.

    As per the example, you would replace [object] with topic.

    <type name="topic">
    [initial status]

    Replace [initial status] with the status the object must be in before it can be set to the target status. If more than one status is possible, include each status in their own <status> element.

    As per the example, you would replace [initial status] with Authoring:revDone and Authoring:work.

    <statuses>
	<status>Authoring:revDone</status>
	<status>Authoring:work</status>
</statuses>
    [group]

    Replace [group] with the name of the group for which the status should be visible.

    As per the example, you would replace [group] with the Technical Writers, Editors, and System Administrators groups.

    <groups>
	<group>Technical Writers</group>
	<group>Editors</group>
	<group>System Administrators</group>
</groups>
  8. Save, close, and check in the accessrights.xml file.

    A complete example of the Status Change section would look like the following:

    <!-- ********************** STATUS CHANGE ********************* -->
<method name="Authoring:edit" type="statuschange">
	<notify enabled="false"/>
	<conditionset operator="any">
		<condition>
			<current>
				<type name="topic">
					<statuses>
						<status>Authoring:revDone</status>
						<status>Authoring:work</status>
					</statuses>
				</type>
			</current>
			<users>
				<groups>
					<group>Technical Writers</group>
					<group>Editors</group>
					<group>System Administrators</group>
				</groups>
			</users>
		</condition>
	</conditionset>
</method>
  9. Inform users of the changes and ask them to close and reopen their CCMS Desktop to apply the changes. Additionally, have an administrator refresh IXIA CCMS Web so that users see the change reflected there.