Folders and privacy
When you set a customer folder as private, the regular inheritance principles are broken.
Breaking inheritance by making a folder private
- Root
- Customers
- Food Company
- Dairy Department
- Bread Department
- GlutenProd
- Gluten-freeProd
- Food Company
- Customers
By default, all folders are public. You have several termbases with the following requirements:
- TB_food must be visible to all Food Company users
- TB_gluten must be visible to GlutenProd users
- TB_bread must be visible to GlutenProd and Gluten- freeProd users
Where do you store your termbases?
- Root
- Customers
- Food Company (store TB_food here)
- Dairy Department
- Bread Department (store TB_bread here)
- GlutenProd (sotre TB_gluten here)
- Gluten-freeProd
- Food Company (store TB_food here)
- Customers
One day, you notice that TB_bread contains content that is suitable for Food Company users, but not for GlutenProd and Gluten-freeProd users. You do not want to move or delete the resource. How do you prevent GlutenProd and Gluten-freeProd users from seeing TB_bread? Set the Bread Department folder as a private folder.
- Root
- Customers
- Food Company (public)
- Dairy Department (public)
- Bread Department (*private)
- GlutenProd (public)
- Gluten-freeProd (public)
- Food Company (public)
- Customers
In brief, setting a folder as private exempts its resources from following the default, upwards, access propagation rules:
- If administrators set a folder to public, the resources (termbases, users and groups) from this folder are visible to the users which have access in its child folders (via groups).
- If administrators set a folder to private, the resources (termbases, users and groups) from this folder are not visible to the users in its child folders. Access to resources is governed by the location of the groups a user belongs to. Make sure users are not included in a group located in the parent folder of a private folder or above the parent folder of a private folder.