Permission Inheritance Model

Use

Permissions in the Portal Content Directory (PCD) and the GPAL repositories are based on a hierarchical inheritance model.

This model is governed by the following rules:

Permissions are inherited from one object to another according to each object's hierarchical location in the Portal Catalog.
- A folder passes its permissions to its immediate subfolders, and so on.
- A folder passes its permissions to unit objects contained in it.
- A unit object passes its permissions to embedded objects contained in it.
Permissions are not passed through delta link relationships or other dependency types.
Permissions are assigned directly to folders and unit objects displayed in the Portal Catalog. If permissions are not assigned directly to a folder or unit object, then they are inherited from their closest parent or ancestor that has permissions assigned directly to it.
You cannot assign permissions to embedded objects that are contained in unit objects (such as iViews in a page or worksets in a role). Objects contained in units always inherit permissions from their respective unit object.
When a folder or object has permissions assigned directly to it, the inheritance of permissions is broken between it and its parent. Any subsequent modifications made to the permissions of the parent objects are not passed to its child objects, unless the inheritance is restored.

Figure 1: Permission Inheritance Model:

This figure depicts a Portal Catalog structure containing folders and objects. Certain objects (such as Folder B and iView 1) inherit their permissions from their respective parents, while others (such as Folder A, Folder C, and Role 1) are assigned explicit permissions and thus do not inherit permissions from their parent. Note that iView 1'' is delta link derived from iView 1', which in turn is derived from iView 1. iView 1 does not transfer its permissions to iView 1' nor to iView 1'' through their delta link relationship. The permissions in iView 1 are inherited from its parent folder (Folder B); the permissions in iView 1' are inherited from its parent page (Page 1); and the permissions in iView 1'' are inherited from its parent page (Page 1') which in turn are inherited from the parent object of Page 1' (Role 1).

Activities

1. Modifying Permissions

In the Portal Catalog, you can manually edit the permissions of any subfolder or object contained in a folder. If you do so, the inheritance of permissions between the subfolder or object and its parent folder becomes disconnected; any future changes you make to the permissions of the parent folder will no longer be passed on to the object or subfolder whose permissions you have modified. For example, a folder you edited may have full control permission, while selected objects and subfolders contained within it may have read/write permission.

The Permission Editor does allow you to reset manual changes made to the permissions of an object or folder and thereby restore the permission inheritance to its parent folder. You can also, with a single command, choose to reset the permissions of all objects and subfolders in a given folder. For more information, see Restoring Permission Inheritance .

Note

You cannot modify the permissions of embedded objects that are assigned to other objects. Embedded objects always inherit the permissions of their immediate parent object, which is a unit object displayed in the Portal Catalog.

2. Assigning Permissions to Roles

Roles function as in a chain, in relation with the following:

Users (in the role principle )
Content, such worksets and iViews (in the role object ).

The chain may be visualized as Start of the navigation path User Next navigation step Role Content End of the navigation path .

Users are assigned to roles with the Role Assignment tool, while content is assigned to roles in the Role Editor.

When you create a role object in the Role Editor, its role principal is automatically added to the list of permissions of the role object and is granted end user permissions.

For information on the various permission settings, see Permission Levels .

3. Assigning Users/Groups to Roles (and vice versa)

The Permission Editor provides a permission setting (called role assigner ) for role objects that enables you to determine which users, groups, or roles are able to perform role assignments to the role principle using the Role Assignment tool.

Since the role principal is automatically assigned permission to its role object , users and groups assigned to a portal role will transparently inherit the permissions of that role, including automatic end user permission. In other words, once you assign a user/group to a role principal in the Role Assignment tool, there is no need to open the same role object in the Permission Editor and again add the users/groups already assigned to the role.

More information: Assigning Roles .

4. Creating and Editing Content

Note the following:

When you use a wizard to create an iView based on a template, the new object inherits the permissions of the folder in which it generated, and not the permissions of the template on which it was created.
When you assign an iView to a portal page, the assigned iView inherits the permissions of that page. Similarly, when you assign a page, iView, or workset to role, the assigned object inherits the permissions of the role.
When you create a delta link or copy instance of an existing PCD object in the Portal Catalog, the new object inherits the permissions of the folder in which it is created.

To see examples illustrating the use of the permission inheritance model, refer to Permission Examples .