Move permissions?

David,

I can offer some brief guidance based on having to address similar cases with many different Windchill clients. Given that access control solutions must be guided by clear, validated business requirements, any specific guidance may or may not fit your overall needs.

1. Do you use the deny setting?

Deny settings should never be used without a full, clear understanding of what that means in terms of object, principal and context inheritence factors. While there is sometimes a compelling business requirement for their use, more often than not simply "Not Granting" a permission will meet the business needs to prevent an action ( I often refer to this as a 'soft deny').

2. We have groups that we assign to the team roles in the Products. I want to keep that. But I don't want the permissions for the group set there. I don't see a way in the policy administrator to set the permissions on a group. What am I missing?

In general, unless the permissions is pervasive across the organization, and not dependent on Product/Library context membership, then permissions should not be managed at the group level. If this is the case, the group level permissions may be managed in the Policy Admin at either the Org default or PDM domains. Generally speaking permissions should be managed at the Team Role level, this insures that anyone assigned to a role, or multiple roles, by either group or individual membership, will have the necessary permissions appropriate for that role. While this has often historically increased the administrative burden for the policy administrator, it insures the users have the necessary permissions across any role they are assigned to. Good news for administrators is that in 10.0 there is a method to define team roles such that they can be managed at the higher level domains (Org, PDM, etc) rather than having to do so in each individual context domain.

3. Can someone explain to me what I'm seeing in this screen shot? There are different permissions set for each of the levels under the Product. What are these?

The screen shots do not give me enough info to be specific. However, the one indicates that you are using Product sub-domains, most likely assigned to specific folders within your Product. The only valid reason for doing this is that you desire significant access control polices be applied to objects of the same type within the same Product context based on some aspect that you are using folders to manage/segregate. As such, you have explicitly determined that you want to apply different permissions to different folders/levels under your Product.

Russ