Portlet attribute mappings

The Domino and Extended Products Portlets rely on a predefined set of Virtual Member Manager (VMM) user and group attributes to function properly, while LDAP server may use a different set of predefined user and group attributes. If a portal attribute is available under a different name on the LDAP server, you can map the portal attribute to the corresponding LDAP attribute. Portal attributes that do not correspond to an LDAP attribute should be flagged as unsupported.

The Domino and Extended Products Portlets use these attributes:

Mapping the attributes below ensures that users see the appropriate values when People Finder displays an individual's User Profile, or when they search by attribute (for example, to find all users who have the same preferred language or whose telephone number starts with the same area code). 

# name of the portal attribute
standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail,ibm-jobTitle,
stateOrProvinceName,countryName,localityName,street,employeeNumber,roomNumber,
preferredLanguage,labeledURI,ibm-personalTitle
 
# name of the LDAP attribute
standalone.ldap.attributes.mapping.ldapName=mail,title,st,c,l,OfficeStreetAddress,
EmployeeID,physicalDeliveryOfficeName,preferredLanguage,url,
personalTitle
If you are using a federated LDAP user registry instead of standalone LDAP, the parameter names are federated.ldap.attributes.mapping.portalName and federated.ldap.attributes.mapping.ldapName.

For detailed instructions, see Adapting the attribute configuration under the section of the contents that explains how to configure WebSphere Portal to use a user registry on a particular platform. For example, if the portal server is running on Windows, locate the topic called Configuring WebSphere Portal to use a user registry on Windows and from there, navigate to Adapting the attribute configuration.


Parent

Collaboration and Messaging portlets


Related tasks


Edit the CSEnvironment.properties file

 


+

Search Tips   |   Advanced Search