Configure access rights by specialization

If your use cases demand it, you can configure user access to features in greater detail.

About this task

Generally, you specify role and group access to features by topic type: topic, map, ditaval, Collaborative Review, etc. Most of the time this is sufficient. However, if you absolutely need to specify access at a more granular level, you can do so.

For example, if you need to specify different Lock permissions for maps vs. bookmaps, you can configure the Lock access right based on specialization.

When you opt to configure an access right using specializations, you must use the specializations for all the object types. In other words, you can't break the map object type out into map and bookmap but then use the general topic object type. You must also break the topic object type out into topic, concept, task, reference, etc. You must also break all other object types out into their specializations, including object types like image, resource Collaborative Review, Snapshot, and so on. As you might imagine, this greatly increases the size and complexity of the access right.

Before configuring an access right using specializations, make sure you have a solid use case for this level of granularity.

For example, without this feature, to give your Writers editing access rights to all the topics and maps, you specify the following conditions in the Lock access right in the accessrights.xml file:

<condition>
   <!-- Object on which action is taken -->
    <current>
        <type name="map">
            <statuses>
                <status>Authoring:work</status>
            </statuses>
        </type>
    </current>
    <!-- Action user must be in this list -->
    <users>
        <roles>
            <role name="Writer"/>
        </roles>
    </users>
</condition>
<condition>
   <!-- Object on which action is taken -->
    <current>
        <type name="topic">
            <statuses>
                <status>Authoring:work</status>
            </statuses>
        </type>
    </current>
    <!-- Action user must be in this list -->
    <users>
        <roles>
            <role name="Writer"/>
        </roles>
    </users>
</condition>

This is straightforward. Compare this example with the example in step 6 below.

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

Procedure

In the TEXTML Administration perspective, connect to your server.
Browse to /system/conf to locate the accessrights.xml file.
Right-click accessrights.xml and select Check Out.
Open the file in an XML editor.
Locate the access right (method) you want to configure and set its @use-specialization attribute to true.
For example:
```
<method name="Edit" type="front-end"  use-specialization="true"    > 
```
If @use-specialization is not present on the method, add it.

Configure conditions as required by your use case.

Taking the example above, say you want to "break out" the map object type and topic object type into their separate specializations, to give Writers Lock rights to maps and bookmaps only and to give Information Architects Lock rights to subjectSchemes. Your new configuration might look like this.

<condition>
	<!-- Object on which action is taken -->
	<current>
		<type name="map">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="bookmap">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
	</current>
	<!-- Action user must be in this list -->
	<users>
		<roles>
			<role name="Writer"/>
		</roles>
	</users>
</condition>
<condition>
	<!-- Object on which action is taken -->
	<current>
		<type name="subjectScheme">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
	</current>
	<!-- Action user must be in this list -->
	<users>
		<roles>
			<role name="Information Architect"/>
		</roles>
	</users>
</condition>
<condition>
	<!-- Object on which action is taken -->
	<current>
		<type name="topic">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="concept">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="reference">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="task">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="glossentry">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="glossgroup">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="referable-content">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
		<type name="troubleshooting">
			<statuses>
				<status>Authoring:work</status>
			</statuses>
		</type>
	</current>
	<!-- Action user must be in this list -->
	<users>
		<roles>
			<role name="Writer"/>
		</roles>
	</users>
</condition>

Notice that even though you don't need to "break out" the topic types, you still have to do so because the entire method is set to use specialization. If you left this condition in the revised access right:

<condition>
   <!-- Object on which action is taken -->
    <current>
        <type name="topic">
            <statuses>
                <status>Authoring:work</status>
            </statuses>
        </type>
    </current>
    <!-- Action user must be in this list -->
    <users>
        <roles>
            <role name="Writer"/>
        </roles>
    </users>
</condition>

only the generic topic topic type would be lockable (meaning topics whose root element is <topic>).

Any specific object type specialization that you don't list in the access right is not covered by the access right at all and no users can perform this action on type of object.

Tip: To see a list of all the specializations for each object type in the CCMS, refer to the equivalence.xml configuration file, where they are all listed.

Save, close, and check in the file.
Inform users of the changes.
The changes are automatically applied once users close and then reopen their CCMS Desktop. Users can also apply the changes without restarting their CCMS Desktop by clicking IXIA CCMS > Synchronize Configuration. Additionally, refresh IXIA CCMS Web so that users see the change reflected there.