The BSCW role concept
BSCW manages access rights via the role or roles that a user holds. Roles are sets of actions that are allowed for the holder of a role. Access control via roles is very simple: Users may carry out a certain action on a given object if and only if their role with respect to the object includes that action. Only permitted actions are offered in the menus.
When users hold multiple roles they may carry out an action if the action is allowed for one of their roles. Users may consequently carry out actions contained in the union of actions resulting from their roles.
Standard roles
As examples of BSCW roles we give a description of the predefined standard roles that are offered when inviting new members to a workspace.
o Member
o read, copy, cut and delete the objects of a workspace
o have the info page displayed
o create new objects, e.g. upload documents, change objects (name, description etc.) and edit objects
o search for objects, introduce version control for documents
o invite new members and remove existing ones
o Manager
o everything a Member can do
o change the access rights in a workspace: assign roles, edit roles, define new roles, allow public access
o Restricted member has read access only, can read and copy objects and have the info page displayed.
o Associate member has access rights similar to a Member, but cannot invite new members and remove existing ones.
Inheritance of access rights: the scope of a role
To avoid explicit role assignment whenever a new object is created, role definitions and assignments are inherited along the folder hierarchy. When a user, e.g., creates a subfolder, this subfolder inherits the member group of the parent folder including all role assignments.
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.
Note: Though this principle is also true for personal containers like the user’s home folder, clipboard or trash, the user’s default role in these special containers is not inherited to shared folders which are contained therein.
An example
You are by default the Manager of your home folder and of all objects and all subfolders therein. The default role Manager is inherited to your home folder’s scope.
We now assume that you are invited to a shared folder called ‘Project Documentation’. The Manager of this workspace invites you in the role Restricted member in order to assign only restricted access rights to you, e.g. only read access. You now hold the role Restricted member for the entire ‘Project Documentation’ folder and its contents.
On the other hand, the shared folder ‘Project Documentation’ appears at the top level of your home folder where you are Manager. What roles will you play in ‘Project Documentation’? If the role Manager were inherited from your home folder to ‘Project Documentation’, you would be both Manager and Restricted member. This would be technically feasible, but most likely not what your host intended. Therefore, the personal containers like the home folder, clipboard and trash inherit their role assignments only to private folders, but not to shared folders. Shared folders inherit role definitions and assignments only from other shared folders.
Extended access rights for the BSCW administrator
BSCW administrators may always assign and redefine roles (actions 
and
) on all folders, independent of their
membership. Besides, they may open all folders and may execute
for all objects.
Because of the extensive rights that a BSCW administrator has (and must have), the property of being an administrator is not a role in the sense of the BSCW role concept and consequently cannot be manipulated via the BSCW user interface.