cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X

ACL's Default vs. Private

vmcdaniel
2-Guest

ACL's Default vs. Private

I'm looking for a reason to not use Private Access / Private Policy domain. I recently set my Products to Private Access = Yes so that the users search results were filtered down to only objects in the contexts they are members of, basically by business unit.
Are there other reasons, or a reason I should switch them back to Default?
As using the checkbox "Search only in contexts I'm a member of" gives the same result.
Is it as simple as: Use Private if you want any access to be only the team, use Default so users can 'see' beyond their memberships?
Cheers!
-Vaughn
6 REPLIES 6

Never checked, but I remember that private cabinets don't inherit rules from the organization. Or am I messing things up?

Met vriendelijke groeten,

Hugo.

This is well discussed in the business administrators guide.

You use private domain as a way to lock down access in that context. Settings are ignored if the enabled checkbox is not checked.

It certainly isn't designed to limit search scope though I suppose you could tweak OOTB ACL's to make this happen. If you want to limit search to only those who are members of the context team, do not place that user, group, or organization in the team. Then, it will only show results where they are a member.

Not sure what exactly you are trying to do. I never use Guest or Members roles. I define my own roles and then their ACL's.


Sent from my Verizon Wireless BlackBerry

Adding to Dave's note...

We don't use Guest (so far).

"Private" is documented in the guide, but the purpose and mechanics didn't seem at all clear until I sat down and played with it for several hours (6 years ago).

We do use the Members Role in most contexts in order to map all ACL's defined at Org level - because so far we use ACL's directly on Groups, not on the related Roles. Members is just an arbitrary Role to "enable" all ACL's in that particular Product/Library.

By the way watch out for the pseudo-Role "Team Members" which is completely different than "Members." Team Members includes all Roles except Guest and Manager.
RussPratt
5-Regular Member
(To:vmcdaniel)

"Is it as simple as: Use Private if you want any access to be only the team, use Default so users can 'see' beyond their memberships?
"


- Pretty much, Yes. Private should only be used when you want the access limited to the team only, often for some period of time at the beginning of a conceptual product of some sort. As stated, the real difference is that the Private domain does not inherit the ACL (and other policies such as Indexing) set for the Org default and Org PDM domains.


"Private" for a Product/Library context has the same effect as the choice "Team Members Only" selection for a Project context.


Russ

bfrandsen
6-Contributor
(To:vmcdaniel)

If you are using Shared Teams in your Products, then Private Access is not
available.
/Bjarne



Russell Pratt <->
25-10-2011 13:41
Please respond to
Russell Pratt <->


To
<->
cc

Subject
[solutions] - RE: ACL's Default vs. Private






"Is it as simple as: Use Private if you want any access to be only the
team, use Default so users can 'see' beyond their memberships?
"
- Pretty much, Yes. Private should only be used when you want the access
limited to the team only, often for some period of time at the beginning
of a conceptual product of some sort. As stated, the real difference is
that the Private domain does not inherit the ACL (and other policies such
as Indexing) set for the Org default and Org PDM domains.
"Private" for a Product/Library context has the same effect as the choice
"Team Members Only" selection for a Project context.
Russ

Site Links: View post online View mailing list online Send new post
via email Unsubscribe from this mailing list Manage your subscription
Use of this email content is governed by the terms of service at:

Thank you Russ, et.al.


By 'memberships' I meant, 'on the team', vs. Member.


Problem was, Users search for keyword, then recieve results from contexts they are not on the team of with some (Secured Information) for context field. By switching the context to Private, they did not see the results for contexts they were not on the team of.


Come yesterday, I go look at the Policy Admin, all my contexts were now in Private domain. Now it is a clear to me why.



In Reply to Russell Pratt:



"Is it as simple as: Use Private if you want any access to be only the team, use Default so users can 'see' beyond their memberships?
"


- Pretty much, Yes. Private should only be used when you want the access limited to the team only, often for some period of time at the beginning of a conceptual product of some sort. As stated, the real difference is that the Private domain does not inherit the ACL (and other policies such as Indexing) set for the Org default and Org PDM domains.


"Private" for a Product/Library context has the same effect as the choice "Team Members Only" selection for a Project context.


Russ


Announcements

Top Tags