Configure the tagging feature by profile type 

Edit settings in profiles-policy.xml to configure the tagging feature for specific profile types.

Before starting

To edit configuration files, use the IBM WAS wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool.

About this task

The tagging feature allows users to assign meaningful keywords to their own profile and other users' profiles, making it easier to find people with a particular interest or expertise. You can control whether users can tag themselves and others by enabling or disabling the tagging feature for specific profile types. You can also configure access control settings for this feature according to profile type.

Notes:

When configuring the tagging feature for a profile type, consider the following:

• When tagging is disabled, the tags widget is not automatically hidden in the user interface. To hide the widget, delete or comment out the relevant widget entry in the widget-config.xml file. For more information, see Manage widgets in Profiles.

• When tagging is disabled for a given user type, the user's existing tags are still searchable; there is no mechanism available for controlling access to the tags from a reading and viewing perspective. If you choose to display the tags widget but you disable tagging for a particular user type, it might cause confusion for your users when search results include tags for a particular profile, but the tags do not display in that profile.

Procedure

To enable or disable tagging by profile type...

1. From the dmgr host:
   cd $DMGR_PROFILE/bin
   ./wsadmin.sh -jython
   execfile("profilesAdmin.py")

   If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, pick the node where the file is stored.
   

Check out profiles-policy.xml:

ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "<cell_name>")

where:

• <working_directory> is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

• <cell_name> is the name of the IBM WAS cell hosting the Profiles application. This argument is required.
  

For example:

ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

Open profiles-policy.xml using a text editor, from the temporary directory to which you checked it out.

Edit the following properties for the tagging feature as needed.

profile.tag

Controls user access to add tags to their profile.

Access levels for this property can be defined using one of the following scopes:


• none. No one can tag the profile of users with the specified profile type.

• self. Users with the specified profile type can tag their own profiles. Administrators can also tag the profiles of users with the specified profile type.

• colleagues_not_self. Only people who belong to the network of the user with the specified profile type, and who have the person role, can tag the user's profile. Users with the specified profile type cannot tag their own profiles.
  Note: If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.
  

• colleagues_and_self. People who belong to the network of the user with the specified profile type, and who have the person role, can tag the user's profile. Users with the specified profile type can tag their own profiles.
  Note: If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.
  

• person_not_self. Users with the person J2EE role can tag the profile of users with the specified profile type. Users with the specified profile type cannot tag their own profiles.
  Note: If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.
  

• person_and_self. Users with the person J2EE role can tag the profile of users with the specified profile type. Users with the specified profile type can also tag their own profiles.
  Note: If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.
  

For example:

<feature name="profile.tag">
  <profileType type="default" enabled="true">
   <acl name="profile.tag.add" scope="person_and_self" /> 
  </profileType>
  <profileType type="contractor" enabled="true">
   <acl name="profile.tag.add" scope="colleagues_and_self" /> 
  </profileType>
  <profileType type="visitor" enabled="false">
   <acl name="profile.tag.add" scope="none" /> 
  </profileType>
</feature>

The code sample above enables tagging for users with the default profile type. Users with the person J2EE role can tag users of the default profile type, and default users can tag their own profiles. Tagging is also enabled for users with the contractor profile type. People in the profile owner's network who have the person role can add tags to profiles of the contractor type, and contractor users can tag their own profiles. Tagging is disabled for users with the visitor profile type.

Save your changes and check profiles-policy.xml back in using the following command:

ProfilesConfigService.checkInPolicyConfig()

To exit the wsadmin client, type exit at the prompt.

Stop and restart the Profiles server.

Parent topic

Configure features by profile type

Related tasks

Manage widgets in Profiles

   

 

});

+

Search Tips   |   Advanced Search