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

[New_10867550]

Hi HelesicPetr,
Our requirement is Only for specific user subFolder should be visible or content within the folder should be visible .
I wanted few confidential folders in Windchill in library context but library ACL's are overriding that subFolder acl so how can we manage folder level ACL.

[HelesicPetr]

Hi @New_10867550 

The deny acl on a same level is preferred and override the grant access on that level. . 

The upper ACL definition can not override lower level definition if the absolute deny is not defined. 

So you have Library level, where are some definitions for ACL and then you have SubFolder ACL definition. 

If you do not want some rights from the Library level, then you have to define DENY ACL on the subFolder level. 

If you use absolute deny on the library level you have to reorganize your ACL definitions. 

PetrH

[New_10867550]

What I need to follow :

As per your reply I should apply the new acl on folder level ?

From Specific Library ->Utilities -> Policy Administration.

2 acl will create -->> 

One is to deny all access except that grp of users for folder type .

2nd one is to give required access to that specific grp

of users for that folder .

But here how can we define to which folder we have to give access .

Will it needs subDomain for that library ?

To create a subFolder in that domain and then apply the creted ACL's.

Write now it override the acl which we have for authors so it is visible to all authors.

[HelesicPetr]

Hi @New_10867550 

You need to activate subdomain acl on the sub folders and yes, for each context and folder you need to define own subdomain where you define the acl that should apply to the folder.

So more folders can use one subdomain but only under one Context - library/product 

PetrH

[New_10867550]

I applied this same using subDomain  created  new folder and created 2 ACL's for grp of some users but here I have applied the acl for specific document type .

And thing is users who are authors or other admins like esi administrator they can access the folder with content .

So again it is like acl is not working on that subFolder with that grp of users for documents.

If i apply same ACL for folder type will it work ??

[LG_10096154]

Access is like an onion, many layers and tears will shed.

I recently completed a library with a folder structure divided between two different organizations (but they could have been Indvidual's or groups as long as the groups are not mixed). We had a top level folder that was "all access" and then two other top level for lets call it "A access" and "B access". For this I used Domains. Just created three Domains (All Access, A and B). Then set an ACL for the All Access domain so that both A and B org could read the Folder. Then on A domain the ACL was for A org to Read the Folder and deny B to Read, etc.

This worked as long as non one from the A domain ever needs to see what is in a Folder in the B domain.

As someone stated, I could overcome that with moving the ACL to the Org and then creating a group of A folks who need to Read in B domain. I have not tested if local ACL allows access when Org denies it. 

This seemed like a simple solution rather than using Security Labels that require server side admin and for the users to actually select them when creating data.

I don't know of a way to create an ACL against a named Folder (@PetrH) if that is what you're suggesting as the Type picker for the subject of the ACL is just a list of Object types. Maybe it's different in a Project.

[New_10867550]

Thank you for your suggestion .

But in our case grp of users are mixed like some of them are admins , authors , , library manager etc. so then it overrides the access so again that folder become open to all not a confidential.

PTC Should provide kind of functionality in windchill itself like workspace so it will be easy to maintain confidential documents from set of users no matter they are admins or authors.

[HelesicPetr]

Hi @New_10867550 

Your need is archivable by ACL but it is lot of work. 

You just need to use deny/Absolut deny ACL on the lowest level. 

Or use Security Labels 

PetrH

[LG_10096154]

Did you look at Security Labels?

In the Folder level security, you can provide and deny access to a user/group/role.

In help, search for "Setting Access Control while Creating a Folder"