4.6 Access rights

Business Collaborator provides powerful functionality to set differentiated access rights for groups or individual users with respect to workspaces, shared folders, individual documents etc. Specific access rights for an object can be assigned to individual users or groups of members of a workspace or shared folder. On the other hand, objects can also be made accessible for anonymous - see section 4.6.6 - access across the Internet. The access rights specified for a user govern what actions they are permitted to perform (and also control the actions which are presented to them by the interface.)

The ability to specify exactly what actions each user can perform on each object in Business Collaborator is extremely powerful. Inevitably, the converse of this great power, is that assigning very specific access rights can be quite confusing for inexperienced users. For this reason, these sections approach setting access rights in a series of steps, starting with switching off groups of damaging actions, such as cut and delete, for members while permitting all actions for owners. The final sections deal with the subtleties of reconfiguring the default groupings of actions and permitting anonymous access to objects.

This section gives a comprehensive description of all the possible changes to access rights which might ever be required.

4.6.2 Default access rights

By default, Business Collaborator sets access rights according to two rules:

All members of a workspace have full access rights to all objects in this workspace -- with two exceptions:

the right to definitively and irreversibly destroy an object on the Business Collaborator server is held exclusively by the owner of the object - see section 4.5;
the right to modify the access rights for an object is held exclusively by the owner(s) of the object.

Non-members have no access rights for the workspace and the objects in it.

The basic mechanism for assigning access rights is inheritance: the access rights set on a folder are the default access rights for all objects inside this folder and so on.

Note 1: Generally, access rights are set for an object's owners and members (see section 4.5). However, the owners and members may change as you go through the hierarchy. Access rights set for members of a folder will therefore not apply to anyone who owns an object within the folder.
Note 2: Members can be added to folders throughout a hierarchy (see section 3.4.2 ). Therefore, the users identified by "Members of [foldername]" will depend on your location in the hierarchy. This impacts on access rights as described in section 4.6.7.
Note 3: If you wish to give a specific user particular rights throughout the hierarchy, you may do so by assigning them individual rights (see section 4.6.5).

The owner of an object can change the initial set of access rights for the object. Therefore, it is the responsibility of the person who creates a workspace to define the access rights to be applied to all objects in this workspace.

4.6.3 Viewing and checking access rights

The access rights which pertain to an object (either the system defaults or those set by an owner of the object) are displayed in the Access Details table on the information page - see section 3.8. This table indicates the groups of actions permitted for individuals who have access to the object. The first column displays the names of the individual workspace or folder members and the subsequent columns indicate clusters of actions and whether that particular user can perform those actions. When you alter access rights, you should also confirm that you have made the changes you intended by checking the Access Details table - see Figure 4.6-1.

In addition,

If you have been denied specific rights for certain objects, the corresponding actions will not be available to you,
If non-members have been given access to an object (see section 4.6.7), the object's action menu will change its background from white - | action to blue. Alternatively, changes to .

Figure 4.6-1: The Access Details table showing which members can perform which actions.

4.6.4 Setting access rights

Only owners (section 4.5) may set access rights on an object. To set access rights,

Go to the info page for the object
Click on View/Change | Access to view the Access rights page - see Figure 4.6-2

On the Access Rights page, the Access rights table shows

in the first column

the name of the object above the names of the groups and individuals who have access to it

in the second column

the Override checkboxes which indicate priority of access rights assigned to individuals or Business Collaborator groups - see section 4.6.8.

in the following columns

clusters of actions above checkboxes which indicate whether or not the user or group in that row can perform these actions

Figure 4.6-2: Changing access rights.

Note: The significance of checkmarks in the Override column is explained in section 4.6.8.

Business Collaborator objects can be accessed by a wide variety of actions and the actions possible will often depend on the type of the object. These actions can be combined into clusters of similar actions. By default, Business Collaborator uses the following clusters:

Get - includes such non-invasive actions as read, download and copy
Get ext(ended) includes the action which permits users to view the information page of an object and hence see the access rights which have been set for the object
Change includes actions such as adding documents to folders and changing attributes of objects
Change ext(ended) the most invasive types of action such as cut and delete
Share (only for folders or workspaces) the ability to alter memberships

Each cluster is a group of actions for which the right to execute the actions may be assigned separately. Grouping the actions together reduces the effort required when altering the access rights. Actions may be moved between columns or into additional columns to permit highly configured access rights to be specified (see section 4.6.9). (Note that such restructured groups apply only at the level at which they are defined they are not inherited by objects which they contain.)

Because the default access rights imposed are mostly inclusive, editing access rights entails denying certain rights for specific users. To do this, the box corresponding to the required cluster of actions should be deselected for the relevant group of users on the Access Rights page.

For instance, to prevent members from being able to edit the membership of a workspace or shared folder, the owner should click on View/Change | Access . Now deselect the "Share" cluster of actions for the Members access group. Confirm this change by clicking on "Update access rights". Finally, confirm the changes which have been made by referring to the Access Details table on the object’s information page.

Setting access rights for individual users or groups, rather than the standard access rights groups is described in section 4.6.5

4.6.5 Specifying access rights for individuals

In some circumstances, you may want to assign specific access rights for individual workspace or shared folder members, rather than simply assigning rights to the predefined groups of users. This may be desirable, for example, when

some members of a workspace who are acting as administrators should be assigned some, though not all, owner rights while the other members are not allowed to invite new members or to rename, cut or delete objects;
a team of editors should be allowed to modify a document while all other members of the workspace are only allowed to read it;
a specific folder should also be used by the members of another workspace while anonymous access (see section 4.6.6) from the Internet should not be possible.

To perform such a customised assignment of access rights, the owner of an object can select a member of the workspace, or group of members, and add them as specific access rights holders by:

Selecting them from the list directly below the Access rights table on the object’s access rights page as shown in Figure 4.6-3. (Names of groups are at the bottom of the list, in the form "Members of [workspace name]".).
Selecting the names to be added and click (Add selected users/groups)

Figure 4.6-3: Selecting members to assign specific access rights to them.

If the selected users or groups are members of the workspace to which the object belongs, they are added to the Access rights table in separate rows below "Members of [object name]" as shown in Figure 4.6-4. Non-members are added in rows below 'Other users' (see section 4.6.7)

Figure 4.6-4: A new row added to the Access table for a specific member.

If a member appears more than once in the Access rights table, e.g. as an individual and as a member of the original Members group, the exact rights which they have are dictated by which rights take precedence - see section 4.6.8. Always check the Access Details table on the info page for the object after you have altered the access rights to check that you have assigned the rights which you intended.

To remove an individual or group from the Access rights table, remove all their rights by ensuring that no checkboxes are checked for this individual or group and click ( Update access rights ) The updated table will no longer contain the row(s) without access rights.

4.6.6 Anonymous access

Under some circumstances, you may wish to give people access to objects stored on your Business Collaborator server without registering them on the system. If you wish to create a set of web pages for a project, it is recommended that you use Business Collaborator’s web site publishing tool see Section 10 - Website publishing. For a single document, you may simply wish to make it directly accessible to an unregistered user. This may be done by giving the anonymous user access to the document.

Note: Objects which are accessible anonymously can be accessed by anyone on the Internet (although they will need to know the web link for the object). All actions carried out by the anonymous user will be recorded as events by anonymous and so the value of the audit history of the object will be somewhat decreased.

Anonymous access must bypass the normal Business Collaborator log in procedure. This is achieved by using an address which differs systematically from the "normal" web link (URL) of a Business Collaborator object. Thus, the web link (URL) for anonymous access to a Business Collaborator object is determined in two steps:

find the URL used by the workspace members to access the object
modify it so that it bypasses the log in procedure and accesses the object directly

Let us illustrate it by the following example:

A PowerPoint presentation, training.ppt, is located in a workspace. 'Get' (i. e. download and copy) access right are assigned to 'Other users' (including anonymous) - for this document.

To members of the workspace, the web link (URL) for the object training.ppt might be shown in the 'Location:' (Address) window of their browser as

http://myserver/bc/bc.cgi/d4339/training.ppt

The bold part of this URL is what must be replaced as indicated below:

http://myserver/pub/english.cgi/d4339/training.ppt

This revised URL indicates that anyone trying to access the object may bypass the log in procedure that is normally started when a user accesses the server. Access control, however, is not bypassed: Business Collaborator returns an error message if anonymous is not allowed to access the requested object.

4.6.7 Standard access rights groups

The three standard groups for the assignment of access rights are Owners, Members and Other users. The Owners group initially contains the creator of the object. Anyone invited to the workspace or shared folder is automatically added to the Members group. Owners and members are discussed in section 4.5.

You can assign access rights to one of these groups as a whole or to Business Collaborator groups or individual users within one of the groups - see section 4.6.5. Other users are users who may be registered on the Business Collaborator server or who may access the object anonymously (see section 4.6.6).

While Business Collaborator's default access rights apply, other users have no access rights. Access rights must be explicitly assigned to this group.

As noted in section 4.6.2, the group of users defined by "Members of [folder name]" depends on your location within a folder hierarchy. If specific access rights are set for "Members of Folder A" and users are then added explicitly to Folder B inside this, the access rights for "Members of Folder B" will be the default access rights for Business Collaborator (i.e. all users can perform all actions) and not those of users who are "Members of Folder A". This is illustrated in Figure 4.6-5 and Figure 4.6-6. Figure 4.6-5 shows the Access details table for Folder A - where all members have restricted access rights. Figure 4.6-6 shows the Access details table for Folder B - where those users who are also members of Folder A have inherited their access rights but the new user (Michelle Haylock) has the default rights of Members of Folder B.

Figure 4.6-5: Restricted access rights of Members of Folder A.

Figure 4.6-6: Access rights of Members of Folder B, contrasting the inherited rights with the default rights.

Warning

If you assign access rights to the group other users, you implicitly endow the user anonymous access with the same rights by default.
To avoid permitting anonymous access in addition to access for registered users of the system, you should,

explicitly include the user anonymous in the Access rights table and
explicitly withdraw all access rights from the user anonymous by selecting the checkbox in the Override column and then de-selecting all other checkboxes in the row for anonymous - see section 4.6.8

Other users can make use of their access rights only if they access the object via a web link (URL) for this specific object - see section 5.3. They must be informed about this link, e.g. as a link on a Web page or by email.

When access rights have been assigned to users who are not workspace members, the object's action menu will change its background from white - | action - to blue, as a reminder to members not to place confidential information here.. (Alternatively, will change colour.)

4.6.8 Precedence of access rights

4.6.8.1 Precedence of access rights among workspace members

4.6.8.2 Precedence of access rights among inherited and non-inherited folder members

4.6.8.3 Precedence of access rights among Other users

4.6.8.4 Precedence of access rights between 'Other users' and 'Members'

The rules governing the precedence of access rights for groups of users and individuals are set out in this section. Default rules defining precedence, as prescribed by the system, may be allied with precedence rules defined by the object’s owner using Override. Generally, checking the Override column forces a setting for a particular user to take precedence over the rights which they have because they already have rights as a member of the object or it overrides the rights which have been inherited from a higher level in the folder structure.

Before setting access rights for a particular group or individual, you should read the relevant section carefully. However, the definitive guide to the access rights currently being applied for a particular object is given by the Access Details table (see section 4.6.3) on its info page.

4.6.8.1 Precedence of access rights among workspace members

If you specify access rights for individual members of a workspace or shared folder(as described in section 4.6.5), by adding workspace members to the left column of the Access rights table, the user names or group names will appear in the rows immediately below the one headed "Members of [object name] ". You can assign rights to them which are different from those assigned to the "Members of [object name]".

Additional rights specifically checked in a row have priority.

Withdrawal of access rights in a row has priority only if the checkbox in the Override column is marked in that row, i.e. if the specific assignment overrides the general assignment. Otherwise, the (more extensive) access rights for the group "Members of [object name]" apply.

Members who belong to several Business Collaborator groups that have been granted specific rights will have the maximum of the access rights of each of these groups (indirect rights assignment).

Note: When assigning rights on an object, always check in the Access details table on the object's info page to see that all users have been assigned the access rights you intended to set. If not, you may find that you have omitted to mark the appropriate checkboxes in the Override column.

4.6.8.2 Precedence of access rights among inherited and non-inherited folder members

As explained in section 4.6.7, members who are added at a specific folder level will initially have the default (open) access rights for that folder. Those who are folder members because they were invited at a higher level (inherited members) may have inherited specific access rights from higher in the folder structure. Changing the access rights of "Members of [folder name]" may therefore affect inherited and specific folder members in different ways. This may be clarified by some examples. For each of the examples below, the access rights set on the parent folder, Folder A, are assumed to be the restricted "read only" rights illustrated in Figure 4.6-5.

To apply more open access rights at the current folder level for specific folder members than have been inherited from above, the access rights page might be edited as shown in Figure 4.6-7a, with results as shown in Figure 4.6-7b. In this instance, the specific folder member (Michelle Haylock) gets greater access rights than the inherited members. Note that the Override column is not checked in Figure 4.6-7a.

Figure 4.6-7a: Access rights settings to give specific folder member(s) greater rights than inherited folder members.

Figure 4.6-7b: Access details table showing specific folder member with greater rights than inherited folder members.

To apply more open access rights at the current folder level than have been inherited from above for all folder members, the access rights page might be edited as shown in Figure 4.6-8a, with results as shown in Figure 4.6-8b. In this instance, all folder members have the same access rights - the Override column is checked in Figure 4.6-8a.

Figure 4.6-8a: Access rights settings to give all folder members greater rights than at the level above.

Figure 4.6-8b: Access details table showing all folder member with greater rights than at the level above.

To apply more restricted access rights at the current folder level than the inherited rights, the access rights page might be edited as shown in Figure 4.6-9a, with results as shown in Figure 4.6-9b. These rights automatically apply to all folder members, irrespective of whether or not the Override column is checked.

Figure 4.6-9a: Access rights settings to give all folder members less rights than at the level above.

Figure 4.6-9b: Access details table showing all folder member with less rights than at the level above.

4.6.8.3 Precedence of access rights among Other users

Users and groups who are included specifically in the Access rights table but who are not members of the workspace (possibly including the user anonymous) are listed in rows below that for 'Other users'. You can assign rights specifically to them which differ from those assigned to the group 'Other users'.

Additional rights assigned specifically in a row below 'Other user' are filtered by the rights of the group 'Other users'; they remain ineffective.

Withdrawal of access rights in a row below 'Other users' has priority only if the checkbox in the Override column is marked in that row, i. e. if the specific assignment overrides the general assignment. Otherwise, the (more extensive) access rights for the group 'Other users' apply.

Note 1: If you wish to give a specific non-member additional access rights for an object, you may do this by inviting them to the folder containing the object.
Note 2: When you assign access rights to the group other users, you implicitly allow the user anonymous access with the same rights by default. To remove the anonymous user’s rights to access this object, you should add them to the table, deselect all the action columns and check Override.

4.6.8.4 Precedence of access rights between 'Other users' and 'Members'

The "Members of [object name]" and the members (and member groups) specifically included in the Access rights table automatically have all the access rights which you grant to 'Other users'.

Explicitly extended rights of the group "Members of [object name]" or of individual members (member groups) apply in addition to those of 'Other users'.

Modified access rights are put into effect by clicking ( Update access rights )

To reset the rights assigned to the Business Collaborator standard groups and default rights assignment, click ( Set default access rights ).

4.6.9 Restructuring access rights

If you wish to assign access rights for specific actions you can change the structure of the Access rights table. You may move actions between Business Collaborator’s standard clusters of actions and define new ones in additional columns. Go to the Access rights page and click

( Change columns ... )

below the Access rights table. This brings up the Action table for [Object name] - see Figure 4.6-10 which allows you to

disable actions for this particular object
move individual actions from one action cluster to a different one
create additional action clusters in new columns
add these by clicking (Add column ...) below the table. Use the radio buttons to indicate which actions should belong to which cluster

For your changes to take effect, click

( Update table ).

To undo any modifications to the table before an update, click

( Clear changes ).

To return to the default set of access rights, click on (Set default access rights) below the Access rights table.

Warning: Changes to the default column groupings of access rights are not inherited. If you change the grouping of actions on a shared folder and then create new objects within the folder, these new objects will have the Business Collaborator default action groupings. It is therefore recommended that you only restructure the access rights clusters in folders at the bottom of your hierarchy.

Figure 4.6-10: Changing the default groups of actions in the access rights table.

<<<<<

Section

>>>>>

Page