Profiles
This topic provides information needed for working with profiles and includes the following areas:
Profiles as a Visibility Control Mechanism
Types of Profiles
Default Profile Behavior for a New User
OverridingProfiles
Default Visibility for Application Context Managers
Global Default Settings
Profiles as a Visibility Control Mechanism
Profiles allow the site and organization administrator to dynamically control which actions are visible to a user, group of users, or users in an organization by associating that information with a profile. A profile represents a typical category of user within a company and is based on the roles and privileges associated with that particular user category. Profiles are not an access control mechanism; they are a user interface control mechanism.
By defining a profile that exposes only the necessary functionality and information needed by a user, it creates a focused and simplified user interface, reducing confusion by eliminating areas of the user interface that could be distracting. This capability allows customers to ensure that a supplier, customer, or group of users is presented with a streamlined and focused set of information and actions.
The profiles that are associated with a user, group, or an organization control which actions and areas of the user interface are visible by those users. A user could have permission to edit an object based on an object domain-based policy, but not have visibility to that edit action for the object because this action is not included in the user’s profile.
The primary goal in defining profiles is simply to hide the user interface elements (for example, actions, tabs, and attributes) that a user has no need for, or interest in the functionality. If a user does not have rights to an object or an action through access control rules, a profile will not add visibility to actions or information that is restricted by underlying access control policies. That is, you cannot grant a user visibility through a profile to an action or an area of the user interface for which that user does not already have access control rights. For example, a user could have access control permissions to the New Part action in the system, but through a profile, that action can be hidden from the user and not visible in the user interface. On the other hand, if the user does not have access control permissions to the New Part action, that action cannot be made visible to the user via a profile. It is the combination of a user being granted permission to an object or action via access control policies, and the profile granting visibility to those actions and objects, that will enable a user to see and perform an action.
Each user or group can be associated with one or more profiles. If the profiles are the same type, then the least restrictive settings for visibility are assumed. For example, if a user is associated with two standard profiles where one standard profile hides an action, but the other standard profile allows visibility of that action, then the user will see the action in the user interface. If one standard profile allows read only visibility to an attribute, but another standard profile gives full rights to that same attribute, then the user will have full rights to the attribute. However, if the user is a member of a standard profile and a license profile and one grants visibility to an action while the other does not, then the action is not visible. If the user is a member of a standard profile and a license profile and both grant visibility to an action, then the user will be able to see that action.
Changes that are made to profiles take effect after the user subsequently logs into the system.
When a profile is associated or disassociated from a user or group, no change in access permissions is implied or enforced.
* 
Profiles do not apply to some actions within workspaces. Use access control rules to manage a participant's access to those actions within a workspace.
Types of Profiles
There are two types of profiles in Windchill:
Standard profiles are managed by Windchill administrators to control visibility of actions, attributes, and user interface elements for the members you select.
License profiles are maintained by PTC and cannot be altered, deleted, or exported. They provide visibility of user interface elements to match the capabilities defined for various Windchill licenses.
License profiles membership consists of license groups through which the capabilities of the profile are extended. To extend the capabilities of a license profile to a user, add the user to a license group that is a member of the profile. License usage compliance is in effect when users have been added to the license groups for the licenses that have been purchased for them. For more information, see Managing License Profiles and License Profile Information Page.
Administrators can choose to further restrict visibility of actions granted by a license profile by adding a user to a standard profile that hides the action. For example, the PTC View and Print Only License profile provides visibility to the View Notebook action. Suppose John is a member of the PTC View and Print Only License group, which is a member of the profile. An administrator can add John to a standard profile that hides the View Notebook action. As a result, John is not able to view the action.
Similarly, if a standard profile provides visibility to an action, but a license profile hides that action, and a user is a member of groups associated with these two profiles, then the user will not be able to see the action. If a license profile and standard profile provide visibility to an action, and both profiles apply to a user, then the user is able to see the action.
Default Profile Behavior for a New User
When a user is added to the system, the user will inherit the standard profile that is associated with the organization of which the user or group is a member. If the organization to which the user is added is not associated with a profile, and the user is not associated with a profile, then the user’s visibility to actions and areas of the user interface will be determined by the default profile system configuration. The user will not be associated with this default system profile but the system will use this profile for the user in the absence of any other profile association.
The out-of-the-box system default profile provides visibility to all functions and areas of the user interface. This system profile may be modified by the site administrator to provide visibility to a minimal number of actions and information elements.
Overriding Standard Profiles in an Application Context
Standard profiles are defined and managed from the site and organization contexts. Standard profiles that are created in an organization context are peers to the standard profiles created in the site context, unless they are given identical names – that is, the system will merge the settings from all standard profiles that are associated with a user, regardless of whether they are defined at the site or the organization contexts to determine what will be visible to the user. When a standard profile is created in an organization context with an identical name to a standard profile created in the site context, the organization profile overrides the site profile.
* 
Standard profiles cannot be given the same name as a license profile.
Standard profiles that are created in both the site and organization contexts can be overridden in a specific application context, such as in a project. For example, assume that a user is associated with a profile that is defined in the site context and this profile does not allow visibility to the actions that would allow that user to create folders in any application context. The Project Manager of that project can override the site-defined profile privileges and allow that specific user visibility to the action for creating folders by configuring the role for the team in which the user is a member.
From the Team page, application context managers can override the visibility defined in site and organization profiles. For more information about overriding visibility from the Team user interface, see About Configuring Action Visibility by Role.
Default Visibility for Application Context Managers
The site and organization administrator can choose to set defaults for and hide control over a specific product, library, project, or other application context action or user interface element. That is, the site and organization administrator can carefully control which elements that application context managers (project, product, and library managers) are able to override in a context instance.
Removing the ability for an application context manager to override a profile setting is done by globally hiding visibility to the Configure Actions for Roles action for a specific context. If this is done, then the visibility of actions and areas of the user interface in a context instance cannot be modified by that application context manager.
If an action or user interface element is allowed to be configured or overridden by the application context manager in a context instance, then the user interface element will be displayed as a row in the Configure Actions for Roles dialog box which is accessed from the Team page.
The site administrator can define a default value (to show or hide) the user interface element but if the user interface element is made configurable in a context, then the application context manager can override the default and choose to show or hide the user interface element per role in the context team.
Global Default Settings
A site or system administrator can globally configure the default visibility for actions as well as the standard out-of-the-box roles. This is done by modifying the out-of-the-box system default profile.
Was this helpful?