Skip to main content
6-Contributor
September 10, 2024
Question

Best Practice for Restricting Role-Based ACLs to Specific Lifecycle States

  • September 10, 2024
  • 2 replies
  • 1797 views

Hello PTC Community,

 

I’ve configured Role A at the organization level to allow users to read and download content only in release-equivalent lifecycle states. However, I’ve encountered an issue where Role A is inheriting the out-of-the-box (OOTB) ACLs assigned to the Team Member role, which inadvertently grants users access (read and download) to objects in all lifecycle states.

What is the best practice for configuring ACLs so that Role A can only access objects in release-equivalent lifecycle states, even when users are also assigned the Team Member role? Any advice on managing role-based permissions effectively in this scenario would be greatly appreciated.

Thank you in advance!

 

Best regards,
Santosh 

2 replies

14-Alexandrite
September 10, 2024

Note: This is not a customization question!

 

In order to achieve your use case, we should understand how access control works in Windchill, it is through access control calculation.

Generally speaking, the strong rule will apply.

 

Please let us know what do you mean by "release-equivalent lifecycle states".

 

You can start with the following documentation: Article - CS364768 - Access Control Calculation in Windchill PLM (ptc.com)

 

 

 

Santosh_B6-ContributorAuthor
6-Contributor
September 10, 2024

Thank you for the clarification!

 

By "release-equivalent lifecycle states," I mean lifecycle states such as Released, Approved, or any custom states that represent a state where the object is considered finalized or ready for general use, as opposed to states like In Work or Under Review where the object is still being developed or validated.

 

I will review the article you suggested on access control calculation (CS364768) to better understand how ACLs are applied.

 

My goal is to ensure that users in Role A can only access objects in release-equivalent states. However, the Team Member role seems to override the ACL, granting broader OOTB permissions.

 

I’d appreciate any specific recommendations or best practices on how to override or fine-tune these permissions so that Role A can have restricted access.

Thanks again for the guidance.

 

Best regards,

Santosh

14-Alexandrite
September 10, 2024

@Santosh_B Try to set an absolute deny policy to this role A on the type of object in question for every state no "release-equivalent states".

HelesicPetr
22-Sapphire II
22-Sapphire II
September 12, 2024

Hi @Santosh_B 

First, ACL knowledge  is really needed, because you can case many troubles to end users.

 

I would say, use different context template where the team member ACLs are not defined.

or rearrange all ACLs to achieve your needs. Yes it takes a time 😄 

 

Check what ACL are defined on the TeamMembers pseudo role and deny this rules on your RoleA

or remove the existing ACLs for the pseudo team role add this rules to individual roles that needs that rights. 

 

It is very complex area how to keep the ACLs rules in the best condition.

 

PetrH