and ).BSCW manages access rights via the role or roles a user holds. A role is defined by a name and a set of actions that are allowed for the role owner. Access control via roles is very simple: A user may always apply an action to a certain object if this action is contained in one of his roles regarding this object. Only allowed actions are offered in the menus at a time.
When users have multiple roles, they are allowed to perform an action if the action is allowed in one of the roles; thus, users are allowed the union of actions that result from their roles.
As examples for BSCW roles, the predefined default roles that are offered when inviting new members shall be used here.
•Member can
o read and copy, cut and remove the objects of a workspace,
o look at the info pages,
o create new objects such as upload documents, modify objects (name, description, etc.) and edit them as far as the object allows,
o search for objects, introduce version control for documents,
o invite new members and remove existing ones.
•Manager can
o everything a member can do, and beyond that
o Change the access rights in a workspace: Assign roles, change roles, define new roles and allow public access.
•Restricted member has read-only rights, so can open objects, copy and view the info page.
•Associate member has access rights like a member, but cannot invite new members or remove existing ones.
So that an explicit assignment of roles is not necessary for each newly created object, definitions and assignments of roles inherit along the folder hierarchy. For example, if a user creates a subfolder in a folder, this subfolder inherits the user group of the parent folder including all role assignments.
The scope of a role is the object for which the user has a role, and everything 'below' that object, until the user is assigned another role in the object hierarchy.
Note: Although this principle also applies to special folders such as the personal areas personal workspace ('home folder'), clipboard, recycle bin, the default role held by the user in his personal areas is not inherited to shared workspaces located in these personal areas.
By default, you are the manager of your personal workspace and thus of all folders within it. The Manager role is inherited on the scope of your personal workspace.
Let's assume that you are now invited to contribute to a shared folder 'Project Documentation'. The manager of this folder invites you in the role Restricted member to grant you only restricted rights, in this case only read rights. This gives you the rights of a Restricted member in the 'Project Documentation' folder and in all subfolders.
On the other hand, the 'Project Documentation' folder is located in your personal workspace, where you are a manager. Which roles are valid for you in 'Project Documentation'? If you would inherit the manager rights also in 'Project Documentation', you would be a restricted member and manager at the same time. This would be technically possible, but would certainly not be in the interest of your host. For this reason, the special personal areas inherit their role assignments only to private folders, but not to shared workspaces. Shared folders can inherit role definitions and assignments only from other shared folders.
BSCW administrators may assign and change roles in all folders regardless of
their current membership (in the Members menu and ).
Because of the extensive rights, administrator is not a role in the actual sense of the BSCW role concept for security reasons. This avoids that the special rights of the BSCW administrator may be manipulated via the user interface.