Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X
Hi All,
We are currently using custom groups mapped to ACLs for permission control. We are interested in using the OOTB roles feature and are wondering what the benefits are to using groups versus roles.
Would anyone be willing to share their experiences?
Thank you,
- Shaylyn
I use to find no difference between Roles and Groups. Both are looking same and I am not sure if we can access Groups at Application container Level ( I assume that it is used at Org level only)
We found lot of issues with the ACL setting at Application container level (we had 20-30 Roles, I guess lot of)..Please dont use OOTB Roles ( I am afraid of using it).
I read somehwere in the PTC guide that, ACLs should be defined at Org/Site Level for better maintenance/easy management.
Still trying to find the difference between Roles,Groups, Profiles and Team (huuh)....
best of luck
Good question, and interesting responses. It is obvious to me that most admins don't really understand the fundamental business rule differences between the use of Groups and the use of Roles. Roles provide much more business flexibility, not the least of which is that Role participation can be managed at the application context level, rather than at the site/org context levels. What I find, and see confirmed here, is that generally the desire of the admin to simply his/her work, the business solution is constrained and limited by a missapplied use of Groups where the core system functionality is designed to use Roles.
That said, there are a couple of features that can be leveraged to get the best of both worlds. One is the use of Shared Teams, the other, and actually more powerful mechanism is to leverage the wtRolePrincipal object (unfortunately not yet well documented).
The gist of the RolePrincipal object is that you can write ACL policy rules for this role at the org context level, and those rules will automatically be inherited by any lower level Context Team Role that has exactly the same name as the RolePrincipal. Net result: I can manage Context Team membership at the context level, but manage the ACL's for all those roles at the Org level.
Unfortunately the "right" answer generally depends on specific business requirements, so I'm not going to attempt to just post a list of recommendations. But I should caution that the use of groups rather than roles to manage all business rules has shown in many cases to be a non-scalable solution in a large complex environment. Yes, it might allow all ACL management at the Org level, but that perceived advantage evaporates with large numbers of groups being created to handle every desired variation in the specific set of permissions that need to be applied.
One specific note as you begin to investigate Roles: ROLES ARE GENERALLY NOT JOB TITLES - Roles reflect responsibilties, not titles, don't confuse the two.
Russ
FYI - PTC wrote a white paper on using dynamic roles called Using Dynamic Roles for Centralized Administration of Access Policy Rules. Appendix A of the paper shows the format of the .xml template file used to load the rules at the Org level (Default/PDM) as well as the wt.load.LoadFromFile command. I used this technique and it worked well. However, it only adds to the rules, not deleting or modifying them.
If anyone has found a way to use wt.load.LoadFromFile to modify or delete existing data, I'm sure the community would be interested in the technique.
Regards,
Daniel Nordin
BAE Systems
I use roles both to assign ACL's and for Promotion & Change Control sign-off. I will also assign a principle user to a role, say Quality Engineer and than the group 'Quality Engineers' to the role. This give me the user to assign to the signature role and access to the Product for the rest of the quality team. This works for us in most cases.
This is my technique for windchill 8.0 production. Havn't gotten far enought test in 9.1 to see how it works...
Kathy