This is an old revision of the document!


Understanding User Rights

In a multi-user environment controlling what a user can do is crucial. If you are a using OpenGoo as a client extranet you probably don't want that one client can see documents of another client. If you are using OpenGoo as an intranet you may have certain workspaces where certain employees are not allowed to edit information, and some other workspaces which are visible to the management exclusively.

Setting the user rights is one of the more complex tasks in OpenGoo. There are properties at serveral places, and you have to know where to find them and how they relate to each other. This page tries to summarize all the different settings that control user rights.

Basically there are to types of permissions: Some apply to your OpenGoo installation as a whole - we call them system permissions. Others can be set per workspace - we refer to them as workspace permissions.

On the level of each single user you can set system permissions as well as workspace permissions.

The system permissions define whether a user is allowed to:

  • edit company data
  • manage security
  • manage workspaces
  • manage configuration
  • manage contacts

(I need more information about how these system permissions work.)

Workspace permissions can be set by checking the checkboxes for the respective workspaces, which gives the user full access to that workspace.

1)

If you want to control workspace permissions in more detail, click on the name of that workspace to bring up the workspace permission details. There you can define for each object type if a user is able to read & write it, to read it only, or not see it at all.

There are two more checkboxes to control how a user can assign tasks to other users. If you activate the first one, this user can assign tasks to users of the owner company; if you activate the second one, this user can assign tasks to users of other client companies. If you don't check any of the two, this user can assign tasks only to users of his own company.

Groups (or roles) are a common concept for dealing with user rights. The idea is that you do not set permissions for every single user but that you can define groups (or roles) with specific rights and add the users to a certain group (or role). This makes controlling and updating permissions much easier.

Unfortunatly groups in OpenGoo are not very powerful. As of OpenGoo 0.9.1 you can only define groups based on the system permissions.

There is also a screen where you can set workspace permission for each company.

PLEASE NOTE: Whether a user can access a workspace or not is defined by the workspace permissions from the user profile (see above), not by the workspace permissions of the company the user belongs to. If you add the permission to access a certain workspace to the company, this permission is not automatically given to all users of that company (you have to add this permission manually for each user). On the other hand, a user can be given permission to access a workspace where his company does not have access rights.

This is a bit confusing, and you may ask what use workspace permissions on the company level are good for. (Good question, and I have no answer!)


1)
It looks like you can control the rights of a user for a workspace can be controlled from both sides, as a property of the workspace and as a property of the user. Are these the same rights?