If you change the ACL on a folder in the portal (Administrative or Knowledge Directory), you're prompted with a question like this:
In general (unless it's a very small folder), if you do want security to propagate, you should select "Yes" for this prompt. What this will do is create a JOB in the Intrinsic Operations folder (typically called "Async Operation for nnn") that applies the security changes.
The reason this is a good idea is that changing the security on all those folders and objects can be a very CPU-intensive process, and isn't always a critical real-time operation (meaning it can wait a couple minutes before starting). Effectively, what you're doing is delegating this CPU-intensive operation to the Automation Server, and eliminating the load on the Portal server, which shares resources with every other portal user on the system.
A word of caution when doing this (whether you schedule the job Asynchronously or not): use extreme caution when allowing these security changes to propagate at all, and make sure you really want the privileges to be the same on all child objects and folders.
For example, suppose I want to add the user "matt" as an administrator for all communities in a particular folder. Also say that there's a community in that folder where "ashish" has administrative access, but he doesn't on the folder I'm about to change.
If I add "matt" to the top-level folder, and choose to propagate security, you'd think the job would just add "matt" to the ACLs for all child objects, like Windows NTFS permissions, right? You'd be wrong. Instead, the job simply copies the ENTIRE ACL from the parent to all the child objects, effectively eliminating "ashish" as an administrator on that child community.
Leave a comment