Access Control in Folders within Project

[LG_10096154]

I know this is a bit of an Onion (many layers and it can make you cry).

We have Org and level Roles with ACL's but we also allow Projects to create Local Roles and these act like "Team Members" for Org level ACL's.

In a Project (or any context) there is also the ability to ride a gui action with Actions on Roles.

Given all that....

There are Access Controls on a Folder (that can be propagated to sub-folders) and these look like ACL in that they say "modify" ,  "modify content" (looks like modify content in ACL), ""The right to modify any local file, URL, or external storage for the primary content and attachments of an object with content. This includes modifying content information and adding, replacing, or deleting content"

If the Role in the team has Modify, Modify Content on the Access Control rule and can see Check Out, Check out and Edit, Replace content. Would selecting only Read , Download only allows those actions, and conversely can you grant Modify if the Role only has Read, download at the Org ACL?

My second question is the Russian doll permissions. If the Sub-folder has Modify for the Role but the parent folder is only Read and Download what do you get?

[Dobi · Accepted solution]

On the second question, if the sub-folder has a Modify ACL granted  through a permission domain but the parent folder only does a read/download, you ought to be able to "modify" (i.e. add content, etc.) to the sub-folder but not the parent - as in: add another sub-folder or add a document at the parent level. I'm pretty sure that's how I had permission set up at a previous company in a Project context. Pretty sure. ... 70% sure. 

For the first question, have you looked at Access Information table under the "Edit Access Control"?

It will show what sum of permissions is granted (and through what role/team participation) so it might help clarify what's what. 

Permissions are additive rather than subtractive so if at the Org level you have a base set of read/download stuff granted, as you work your way down to contexts or further sub-domains (assuming you don't have private access checked), you can just add additional access and it sums the total at the lowest level you're at where that access is enforced. 

For example: you can have a global read/download set at the Org level for everyone but then have a sub-domain applied to a folder where a subset of people have modify access just at that domain. In that folder where the domain is applied, everyone can read/download but only the subset of people can modify. 

[Dobi]

You can, equally, have a read/download/modify permission at an Org level for everyone but then in a particular sub-folder have a deny read to everyone except a certain user or role. That lowest level permission works so only your user or role will see that the sub-folder exists while everyone else will not. 

It gets tricky if you're using roles and groups together though. I've seen weird behavior where there's conflicting rules between a group participant and a role participant and Windchill doesn't resolve those cleanly. 

[HelesicPetr]

Hi @Dobi 

I agree that there is very unexpected behavior if ACL are defined on the group and also role . 

Persons ACL in the group and role can not be clearly identified. 

so I do advice, never try to combinate ACLs with groups and roles together.

PetrH