Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X
I am fairly new to customized company Standard Profiles (and license profiles), but have been learning how important they are, and how many issues arise, esp. in WC12.
Solved! Go to Solution.
A few comments.
1.) As a general rule, standard profiles turn off visibility for actions the user already has rights to perform.
2.) To figure out which actions control which buttons, it's helpful to create a couple of test profiles - one with everything turned on and another with everything turned off. You will quickly discover that there are many commands and buttons not controlled by the standard profiles at all (they are always visible.)
3.) As mentioned in one of the linked help pages, profiles add together. If you don't want someone to have access to something, then *all* of the profiles they are associated with must have that thing turned off. For this reason I tend to build profiles that only turn on the things I want each group of users to have. If a user is in more than one group, then they are allowed to access the sum of all associated profiles.
4.) License profiles override standard profiles. If a license profile does not allow display of a certain action, adding that action to a standard profile won't turn it on.
5.) Probably not relevant to what you're doing, but both license profiles and standard profiles draw from the same list of command and actions. This is super annoying if you want to add extra actions to the standard profiles because the same actions instantly become limited to the license profiles as well, even if licensing isn't supposed to have anything to do with your custom actions.
6.) As far as how to assign them, I've chosen to associate each license profile with certain ORG and site level groups. Anyone who is associated with any of those groups is automatically associated with the corresponding profile(s). I never manually assign a profile to someone. This same approach is used for both license profiles and standard profiles.
Hi @LawrenceS ,
Please refer below windchill help center link topics which help you to understand the use of Standard and License profiles and information about each profile:
The above link helps you to understand licensing in more detail.
Hope this helps you.
Thanks,
Pravin Shinde
Thanks for your response and the references. Which questions do these posts answer? Even the terms that I mentioned don't appear to be in any of the documentation that you sent?
I'm also still hoping someone can help with best/good practices for working with the different methods of controlling permissions.
A few comments.
1.) As a general rule, standard profiles turn off visibility for actions the user already has rights to perform.
2.) To figure out which actions control which buttons, it's helpful to create a couple of test profiles - one with everything turned on and another with everything turned off. You will quickly discover that there are many commands and buttons not controlled by the standard profiles at all (they are always visible.)
3.) As mentioned in one of the linked help pages, profiles add together. If you don't want someone to have access to something, then *all* of the profiles they are associated with must have that thing turned off. For this reason I tend to build profiles that only turn on the things I want each group of users to have. If a user is in more than one group, then they are allowed to access the sum of all associated profiles.
4.) License profiles override standard profiles. If a license profile does not allow display of a certain action, adding that action to a standard profile won't turn it on.
5.) Probably not relevant to what you're doing, but both license profiles and standard profiles draw from the same list of command and actions. This is super annoying if you want to add extra actions to the standard profiles because the same actions instantly become limited to the license profiles as well, even if licensing isn't supposed to have anything to do with your custom actions.
6.) As far as how to assign them, I've chosen to associate each license profile with certain ORG and site level groups. Anyone who is associated with any of those groups is automatically associated with the corresponding profile(s). I never manually assign a profile to someone. This same approach is used for both license profiles and standard profiles.
Thank you for the detail loaded and helpful reply!
6.) I like the idea of the groups, and I chose to do the License profiles this way by creating specific license groups. However, it sounds like you have gone a step further and associated multiple profiles with groups. At least with the License groups we were cautioned against not assigning more than one of the same type of License group (e.g. View&Print and Base) to the same person because then it would reserve/pull licenses for both. Is this what you are doing, or do you only do that for the custom profiles where you add more and more functionality depending on their role?
No, only one profile per license group. I add each user to multiple ORG level groups in order to grant them access to different roles, but their top level Active Directory group is only ever associated with one license group, one license profile, and one standard profile. Any other limitations to their functionality are role and context specific ,and handled by the access control rules for each context.
Obviously larger organizations are going to have more complex licensing requirements, but this is what we have:
I'm going to have to think about this some more. Thanks for the additional explanation and the helpful picture!