Show TOC

 Authorizations

Use

Authorization Logic

Authorizations in cFolders always contain an object (such as a folder or a document), an activity, and a user. You can assign an authorization for an object to a user explicitly, for more information, see Object Authorization , or the user receives authorization implicitly, by inheriting authorization through the roles or user groups assigned to him or her. For more information, see Authorization Types .

You can use authorizations effectively in two ways:

  • If you want a user to have access to one specific object only, you can assign the user the appropriate authorization (read or write) and send a notificacation. The collaboration containing the object is not displayed in the collaboration overview; the user can only access the object via the link in a notification.

  • If you want the user to see the collaboration requiring his or her participation in the collaboration overview, you must assign at least read authorization at collaboration level and then adjust the authorization for individual objects if necessary.

Features

The basic rules that govern authorizations in cFolders are as follows:

  • Authorizations are inherited through a hierarchy.

    Example 1: Folder A has subordinate folder A.1. Steve Gates has write authorization for folder A. This means that he automatically has write authorization for folder A.1, too.

  • User authorizations override authorizations from user groups or roles; authorizations from user groups override authorizations from roles. If a user is assigned to two user groups and the user groups have different authorization for an object, the higher authorization has priority.

    Example 2: In folder A, user Steve Gates has read authorization. In addition, user group Product Managers has write authorization. Steve Gates belongs to this user group. However, since user authorizations override authorizations derived from user groups, Steve Gates has read authorization for folder A.

    You can display all authorizations for an object by choosing Start of the navigation path Additional Functions Next navigation step Overview Next navigation step Filter by User Next navigation step New Selection End of the navigation path from the object detail screen. However, the system only displays explicit authorizations and not implicit authorizations.

  • Local object authorizations override inherited authorizations if the local and the inherited authorizations are of the same authorization user type (user, user group, or role).

    Example 3: Bill Ellison, an administrator for folder A.1, sets read authorization for Steve Gates in folder A.1. This restricts Steve Gates’ authorization because the local authorization (folder A.1) overrides the inherited authorization (folder A).

  • If a user has an inherited authorization that is of a different type to the local authorization, for example, one is an authorization from a user group and the other is a user authorization, then rule 2 applies only. The local authorization cannot override the inherited authorization in this case:

    Example 4: Steve Gates has read authorization for folder B and for the subfolder B1, which has inherited this authorization. User group Product Managers, which Steve Gates belongs to also has write authorization for subfolder B1. In this case, the valid authorization for Steve Gates is read authorization because this is a user authorization. Although local object authorizations generally override inherited authorizations, user authorizations always override authorizations from user groups.

    Exception

    An object can also have authorizations that are defined by the status of the object. These authorizations override all other possible authorizations. For more information, see Object Authorizations per Status .

  • When objects are copied, the authorizations are not copied with them. The copied object inherits the authorizations from higher-level objects at the next level of the hierarchy.