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 re­sult­ing from their roles.

Standard roles

As examples of BSCW roles we give a description of the pre-defined standard roles that are offered when inviting new members to a workspace.


read, copy, cut and delete the objects of a workspace

have the info page displayed

create new objects, e.g. upload documents, change objects (name, description etc.) and edit objects

search for objects, introduce version control for documents

invite new members and remove existing ones


everything a Member can do

change the access rights in a workspace: assign roles, edit roles, define new roles, allow public access

Restricted member has read access only, can read and copy objects and have the info page displayed.

Associate member has access rights similar to a Member, but cannot invite new mem­bers 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 as­signments 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 ob­ject, 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, clip­board or trash, the user’s default role in these special containers is not inherited to shared fol­ders 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 re­stricted ac­cess rights to you, e.g. only read access. You now hold the role Restricted mem­ber 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, clip­board 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 action  Access    Assign Role  and action  Access    Edit Role ) on all folders, independent of their membership. Be­sides, they may open all folders and may execute action  Information    General  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 conse­quently cannot be manipulated via the BSCW user interface.