Example: Adding a new security role for teamspace members
When creating a new role, keep in mind that roles are available to all teamspaces and use role names that are easily recognized by users. This helps the creator of a teamspace to decide which role to assign to each member of the teamspace.
When you create a new role, you have the option of designating the role as a member or guest. Members can be added to a teamspace when the teamspace is created, while guests are added later. See Additional considerations when deleting or renaming existing roles if you plan to remove or rename a role.
Use the Security role worksheet to plan the security settings for your roles.
Create the role definition file
- Copy the role definition file for a teamspace member (Teamspace Member Role.xml), and rename it to reflect the name of your new role. (See Example Teamspace Member Role.xml file.)
- Change the label and description in the new file to reflect the new role.
- Change the symname in the new file. The symname is a symbolic name that is used to specify a collaboration object (in this case, a user role). The symname must be unique. The symname maps to the string (via the appconfig.xml file) that determines what a user will see in the selection list when they assign a role to a teamspace member or guest, so it is important that it be unique and that it reflect the role accurately.
- Change the type, if you wish. The value of the type element can be either member or guest, and determines whether this is a member role or a guest role. The main difference is that guests are added after the teamspace has been created, through the People & Teams tab. Members can be added and assigned roles when a teamspace is created.
- Change the access alias assignments in the file as needed. Provide an access alias for each teamspace object. If you do not provide an access alias for a teamspace object, no permissions are granted to that user role for that object. Refer to your completed worksheet, and the Example Collaboration Access Alias Definitions.xml file as needed. Refer to Default access alias definitions for a description of each of the available access aliases provided with the application. (You may also use your own customized access aliases.)
- Check the modified file in using the Collaboration Security Role Definition document class. You must use this document class to ensure that the new role is recognized by the application. (The software determines which roles are available by querying the object store for all files with the Collaboration Security Role Definition document class. The matching files are added to the Collaboration Store.)
Add custom access aliases to the Collaboration Access Alias Definitions.xml file
- If you created a new custom access alias definition, you must add it to the Collaboration Access Alias Definitions.xml file.
- Open the Collaboration Access Alias Definitions.xml file for editing. (See also Example Collaboration Access Alias Definitions.xml file.)
- Add the new access alias to the file, using the symname you assigned to the access alias. Use include statements to specify the security rights. (Refer to the file for examples.) In general, build your custom access alias by combining other access aliases.
- Add specific permissions, if you wish.
- Save the file and check it in using the Collaboration Configuration document class.
Add the new role to the appConfig.xml file
- If you created a new role, you must also add an entry into the appConfig.xml file to map the symname of the role to the resource key for the label. The resource key for the label defines what string a user will select when they add a member to a teamspace and select the role.
- Open the appConfig.xml file for editing. (See also Example appConfig.xml file.) The file is installed by default at C:\Program Files\FileNet\Collaboration\WEB-INF\config.
- Within the file, roles are identified by the <access-level> tag. Locate the current list of roles, and add an entry for your new role. For example:
<access-levels>
<access-level name="admin-security-role">
<label localKey="cwexml.appConfig_xml.adminSecurityRole">Teamspace Administrator</label>
</access-level>
<access-level name="member-security-role">
<label localKey="cwexml.appConfig_xml.memberSecurityRole">Teamspace Member</label>
</access-level>
<access-level name="visitor-security-role">
<label localKey="cwexml.appConfig_xml.visitorSecurityRole">Teamspace Visitor</label>
</access-level>
<access-level name="MYNEW-security-role">
<label localKey="cwexml.appConfig_xml.MYNEWSecurityRole">MY NEW USER ROLE</label>
</access-level>
</access-levels>
where the name is the symname defined in the role definition XML file, and the label identifies the resource key for the string you want to display to users when they add a member to the teamspace.
- Open the resource file cwexml.strings.<locale>.prb for editing. This file is located by default in the Collaboration\TCM\WEB-INF\resources folder on the Collaboration Engine. (The <locale> identifies the language and locale. You may have different versions of the resource string file for different localized versions.)
- Add the string for your new security role to the file. Your entry might look like this:
cwexml.appConfig_xml.MYNEWSecurityRole=MY NEW USER ROLE
Recycle the Application Server, restart the Collaboration Engine and test
- You must recycle the Application Server and restart the Collaboration Engine before your new role definition file and the changes to the Collaboration Access Alias Definitions.xml file take effect.
- Restart the TCM application.
- To verify that your new role is available, select an existing teamspace, then select the People & Teams tab. Select update members. Select a member (or add a new one) then examine the list of teamspace roles available. You should see your new role included in the list. (If you added a new guest role, you will need to check the roles available for guest members.)