Groups

Groups are a useful tool for managing workspace membership and access rights. In particular, you can use a member group to store and edit the assignment of people to roles and their associated access rights in a single place.

If you organize your workspaces via groups, new users can be invited to the corresponding groups and thus get access to all relevant workspaces without much effort. In addition, the group folders serve as interest-related exchange folders or distribution lists.

You may make this information available to all users of your BSCW server by making the group visible when inviting them to workspaces. This makes the group as a whole available for invitation to any workspace. Membership and role assignment in the group is automatically updated on changes in all places where the group appears as a whole.

      Create workspaces for those smaller groups of people who, by their function or the task they are working on, are important for your application area in BSCW and whom you want to treat as a group.

      Open the menu to  Manage Members.

      Select Reveal Group from the top menu to make the group as a whole available to all users of your BSCW server for invitation to workspaces. The button turns blue. The name of the group corresponds to the 'workspace name'. Click [OK].

Note: By default, this action is for managers only. Also, new members must have been invited on this folder.

      You (and other users) can now invite these member groups as a whole to any workspaces: in the 'Add member' action form. The groups become members of the workspace as a whole.

If you want to undo the inviteability of a member group,

      select Reveal Group in the top menu of such a workspace or on its member page. The button will now no longer appear in blue.

Figure 52: Using groups

 

Note: For member groups of community workspaces, i.e. workspaces with a community as a member, the availability for invitations to other workspaces is determined by the community's admission policy. In case of a hidden community, the member group of the corresponding workspace cannot be invited to other workspaces, in case of closed and open communities that are visible to all users anyway, this is possible. Therefore, the action Reveal Group is not possible for such member groups.

If you invite the member group of a workspace X to a workspace Y, 'members of X' become members of 'members of Y', i.e. 'members of X' are included in 'members of Y'. This relationship between groups of members implies the inverse relationship between the corresponding workspaces: Workspace Y automatically becomes part of workspace X, i.e. is contained in workspace X (see also 5.1.4.2 Embedding one workspace into another, where workspaces are embedded into each other with analogous consequences for the member groups).

Note: All members of an invited group get the role regarding the workspace they are invited to - only the restricted members become anonymous members (so they have only reading rights, no info rights anymore). If a member has several roles due to such an invitation, he/she has all rights resulting from the different roles.

You may use this mechanism to map a hierarchical organization to BSCW workspaces and their member groups. First create workspaces for all organizational units, then invite the users belonging to the lowest units to the corresponding workspaces and add the member groups of these workspaces to their address book. Next, invite the member groups of the lowest units to the workspaces one level higher to which they belong (plus some managers and staff members, if necessary). By working your way up the organizational hierarchy in this way, you create a corresponding hierarchy of member groups and workspaces.

Note: If you plan to create large groups of members, where the vast majority of members have the same role, you should consider using communities to reduce the load on the server.