![]() ![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
4.7.1 The BSCW role conceptRoles are sets of actions that are allowed for the holder of a role. Users can be assigned one or more roles for an object at the same time. When a user holds a role, she may execute an action on the object if and only if the role includes that action. If a user holds multiple roles for an object, she is granted permission to the union of actions of all roles. Inheritance of access rights: the scope of a role The scope of a role is the object for which a user holds that role and everything inside the object, unless and until the user is re-assigned another role. The role is thus valid for the object's scope: the object itself and its contents recursively. Roles are said to be inherited from a container object to its contents. Though this is also true for special containers like user's Home or Clipboard, the user's role in those special containers are not inherited to shared folders which are contained therein.
Example: Assume that the user is now invited to a shared folder called Project Documentation, the inviting user assigns a role to her, say guest. The new member then holds the guest role for the entire Project Documentation and its contents. Extended access rights for the BSCW administrator
BSCW administrators may always execute the actions Because of the extensive rights that a BSCW administrator has (and must have), the administrator is not a role in the sense of the BSCW role concept for security reasons. It must be avoided under all circumstances that the property of being a BSCW administrator can be manipulated from the user interface. |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |