Post-migration steps for profile types and profile policies

Overview

In Connections v5 the data model for profile-type definitions has been moved from profiles-config.xml to profile-types.xml. For each apiModel element previously in profiles-config.xml, a corresponding profile-type is declared with the associated properties.

The rules for presentation of a profile have been moved from profiles-config.xml to a set of FreeMarker template files. For each profileLayout element previously defined in profiles-config.xml, a corresponding profile-type is declared or merged with the definition derived from the apiModel.

If the deployment associates a profile-record with a profile-type that was not previously declared in profiles-config.xml, manually define the type in the generated profiles-types.xml to make the system aware of the properties to be associated with that type. If we reference profile-type identifiers in either profiles-policy.xml or widgets-config.xml that were not previously declared in profiles-config.xml, manually declare these profile-type definitions in the generated profiles-types.xml to enumerate the set of properties to be leveraged at run-time.

User interface template files

The following template files now control the rendering of a profile record in the user interface. Each template file is generated based on previous layout definitions present in profiles-config.xml.

File	Generated using	Used for
profileDetails.ftl	profileLayout elements from profiles-config.xml.	Main profile page.
profileEdit.ftl	profileLayout elements from profiles-config.xml.	Input controls when editing the profile.
searchResults.ftl	searchResultsLayout elements from profiles-config.xml.	Directory search and report-to chain application views.
businessCardInfo.ftl	businessCardLayout elements from profiles-config.xml.	Display profile properties on the business card.

The migrated template files should preserve the behavior of the previous releases layout definitions. Review the generated template file, and leverage the features of the FreeMarker template language to simplify the result of each migrated file.

If there were multiple profile-type layouts defined, each migrated file will have a set of if-elseif-else logic to handle profile-type specific rendering behavior. It is often the case there were common rendering semantics across profile-type layout definitions, and as a result the migrated file may appear to have redundant content that can be removed or cleaned up.

LotusConnections-config.xml

If the Profiles customization included custom strings, ensure the custom resource bundle is properly registered in LotusConnections-config.xml, and you have manually applied the custom resource bundle to the target deployment.

If we have modified profiles-policy.xml in prior releases, manually update it again with the same changes, or copy and replace the profiles-policy.xml file in the target release.

Related:
Customize Profiles
Customize display using templates
Add custom strings for widgets and other specified scenarios
Profile-types