Restrict the visibility of status options by group

You can configure a particular status to be visible only to certain groups.

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.

For example, suppose your workflow is represented by the following figure. If you have a topic in the status of Authoring:revDone and you open the Change Status dialog box, your choices are Authoring:edit, Authoring:review, and Authoring:work by default. If you do not want your subject matter experts (SMEs) to push a topic to the Authoring:edit status, then you can hide that status from the SME group.

Figure 1. Example of a workflow for a topic Example of a workflow

To configure the statuses seen by role:

  1. Open the TEXTML Administration perspective by clicking the TEXTML Administration shortcut on the tool bar. If the shortcut is not displayed, follow these steps:
    1. Select Window > Open Perspective > Other
    2. Click TEXTML Administration.
    3. Click OK.
  2. In the TEXTML Administration view, double-click the server. If your server is not displayed in the view, you must add it to the view.
  3. When the Connect as dialog opens, type your username and password and click OK.
  4. Double-click the name of your docbase to open a connection to the Content Store.
  5. Expand the Content Store's Repository node and browse to /system/conf/ to locate the accessrights.xml file.
  6. Right-click accessrights.xml and click Check Out.
  7. Double-click the file to open it in the XML editor area.
  8. Locate the section that begins with:
    <!-- ******* API METHODS DO NOT MODIFY ******* -->
  9. 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>
  10. Edit the template to suit your needs, as follows:
    Option Description
    [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>
  11. Save, close, and check in the accessrights.xml file.
  12. Inform users of the changes.
    The changes will be applied automatically once users close and then reopen their DITA CMS. Users can also apply the changes without restarting their DITA CMS by clicking DITA CMS > Synchronize Configuration.

Therefore, 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>