7. Access Rights

The Cerebro permissions system allows you to configure the scope and availability of functions for groups and individual users.

A permission (access right) – is a right to see, add or edit objects or oblect properties within a definite scope. The scope can embrace the whole “universe” (working area of company), a project or even a single task.

7.1. Permission List

There are two types of the access rights: unconditional and conditional (i.e., triggered when the user is being allocated/dismissed to/from the task). The conditional access rights are applied only to those tasks where the user is allocated as assignee. It should be noted that not all permissions have the “conditional” option.

Below is a table of all the permissions that form access rights in Cerebro.

Name The conditional option Description
Access rights v The ability to set access rights to users and groups in a given area.
Visibility v Visibility problems in a given area and all the messages in them.
Visibility for clients Visibility problems in a given area, and only those messages in them that are marked as visible to customers.
Working with tasks
Task management The ability to create and delete tasks. When installing on the universe, you can create and delete projects.
Editing the properties of a task v The ability to edit properties of the problem in a given area (except the budget and tags).
Editing task tags v The ability to edit tag values for the problems in a given area.
Tasks budget management v Ability to set the budget and make payments on the tasks in a given area.
Editing task progress v The ability to change the progress of tasks in a given domain (do not allow to put 100%, ie to transfer the problem into the Completed state).
Task clock visibility v Allows you to see upcoming, declared and adopted task hours in a given area.
Working with messages
Task formulation v Ability to create Task formulation type messages.
Review v Ability to create Review type messages.
Report v Ability to create Report and Report for the ressource type messages.
Note v Ability to create Note type messages.
Client review v Ability to create Client review type messages.
Editing the message properties v The ability to edit the message properties in a given area, such as Client visibility and Hour confirmation.
Editing the last message v Allows you to edit messages of other users if they do not have an answer.
Editing of any messages v Unlimited editing of any messages in the specified area.
Working with the universe
User management Allows you to create and delete users, groups, roles, and customize the appearance of people. * Valid only at appointment to the universe. *
Material management Allows you to create and delete resources. Valid only at appointment to the universe.
Salary management Ability to define users and resources to see the total bet and salary statistics. Valid only at appointment to the universe.
Tag and activity management The ability to create and delete tags and activities. Valid only at appointment to the universe.
File Storage management Ability to establish and configure a file storage. Valid only at appointment to the universe.

There are permissions that are applicable to the universe level only. For example, such as permissions as Salary Management and Managing users, groups and roles. These permissions apply only to the global properties of the universe. Alongside with those, there are permissions that may be applied either on the global or on the local level, such as Access Rights and Budget Management. These permissions, being applied on the global level, will be inherited (if allowed) by all subordinate levels (all projects and tasks within the universe).

Permissions are additive, that is, if a user members in several groups, each group with different permissions within the scope, the user’s resulting permission will be the sum (appositon) of all permissions available to these groups.

7.2. Permission Inheritance

When configuring a permission to an object, the following options are available as the scope / application area (in parentheses are the alternatives, depending on the level of the object: a task, project, or the universe as a whole):

  • to this task and its subtasks (to the project and its tasks, to the universe and its projects);
  • only to this task (only to this project, only to the universe);
  • only to the subtasks (only to tasks, only to the universe).

Inheritance of permissions on the tasks at lower levels can be canceled, replaced by another set of permissions, or removed. For example, if you want a certain group of users to see the entire project, except one of the tasks in it, then you should set the “visibility” permission on “the project and its tasks”level, and then reset the inheritance on the particular task level. Thus the group will have the right of access to the entire project, except this task and its subtasks.

Note

Reset of permission inheritance gives you the flexibility to control access rights, but at the same time this feature makes the administration process more complicated. So, don’t overuse it.

When permissions are applied to the underlying objects (the third option, see above), the user is given limited permission to the parent object itself and can only partially see it. In this case, the limited visibility of the object means that the user can not see some of its properties, such as hours, budget, etc.

7.3. Roles

There are more than 20 different permissions that form access rights, so for ease of use they are bundled in sets of rights - roles. In the end of the day, it is the role (predefined or custom) that applies to the universe / project / task for groups and individual users.

There are several predefined roles in Cerebro, which differ by access level:

  • Full control - a full control over tasks and subtasks: creating subtasks, deleting, changing their properties, assignees, writing messages of any type, etc. Being applied on the universe level, this role grants access to all Administrator’s functions: add / delete users, create new projects, etc. This role is forbidden to edit, as the system needs at least one user at any time, that has full access to it.
  • Producer – a role designed for a financial manager. It grants access to budgeting and salaries (see ch. “Budgeting”).
  • Supervisor – the role grants the widest options to manage tasks and their properties, practically, the unlimited access in this scope, except several minor features (e.g. to create Client’s Reviews).
  • Client – a special role for the team’s outsiders (e.g., clients). It enables the option to create messages of a special type - Client’s Reviews but limits the visibility of other messages to those only that are marked as Visible for clients (see ch. “Forum”).
  • Worker – a role for the most part of the employees. It enables the options to create Reports and Notes and adjust the Task Progress value up to 99%, but not to set it “Done”.
  • Restricted Worker – a role for team memebers with restricted access to project data (e.g., for freelancers). It enables the option to see and operate only the tasks where the Restricted Worker is an assignee. Within this scope the access level of the Restricted Worker is equal to the one of an ordinary Worker.

You can use these presets or create custom roles of your own.

Note

You can check out the particular permissions for the predefined roles in Cerebro’s Access Rights window.

If you need to create a custom role, ir can be done in the Roles window, which is accessible from an Access Rights window of any object (universe, project, task).

_images/cerebro_roles.png

This window displays current permissions for the roles, besides, it allows to create, edit or delete them.

Note

The Full Control role is protected from editing or deletion.

On the left side there is a list of roles existing in the system, on the right side - the list of permissions for the selected role. The list consists of three columns:

  • Name – the permission’s name
  • Unconventional – an option to enable the permission without any conditions;
  • Conditional – an option for a permission to take effect only when the user is allocated to the object as assignee.

If you hover the mouse cursor over the name of the permission, a tooltip with its description appears.

7.3.1. Creating a New Role

A new role is never created “from scratch”, you need to pick one of the existing roles to serve as a template for the new one. So, first, pick one of the existing roles and press the New role button (above the list of roles).

After that you can specify the name for the new role and edit its permissions in the right side of the window.

7.3.2. Editing a Role

To set/edit a role name, double click its name or use the “Rename” button above it.

There are two columns with checkboxes in the right side of the Roles window – Unconditional and Conditional. You can configure the particular permission set for the role by checking/unchecking the boxes. Each permission may have only one option selected – either unconditional or conditional (if applicable).

Note

If you change a permission set for the role that have already been in use in your universe, the changes will affect all groups/users that are allocated to the role.

Some permissions are logically related to each other. For example, if you switch on the Task management permission for a certain role, it makes sense to activate the Task Editing and New Task Creation permissions as well, as they all are needed for full control over the tasks.

7.3.3. Deleting a Role

Pick a role in the list and press either the Delete Role button in the interface or Delete button on your keyboard.

Note

If the role being deleted is in use in your universe, it will not affect the users/groups that have been allocated to the role. That is, the deletion just removes the item from the list. If you want to discard permissions for the users/groups associated with the deleted role, you need to do it manually in the access settings for the corresponding objects.

Any change (creating or editing a role) must be confirmed by pressing a Confirm or OK button. If you want to discard the changes, press a Roll Back or Cancel.

While you are making changes to the roles, the lower part of the window displays comments how the change will affect the role or, in certain cases, why the change is impossible to make this way.

7.4. Setting Access Rights for a Task

The access rights for projects/tasks are set up on the Task Properties tab (see ch. “Task properties”).

Note

In terms of Navigator, a Project is a root-level task in the tree structure.

To assign access rights to a task selected in the Navigator, go to the Task Properties tab and click the Access rights icon in the top right corner - a window with access rights will open:

_images/cerebro_task_permissions.png

The upper list displays groups and users who have any access rights to the selected task. The list contains four columns:

  • Group/User Name;
  • Role – the name of the role given to the group/user;
  • Applied to – displays the objects the role is applied to
  • Inherited From – the name of the parent object from which the current object inherits the access rights pattern (role). If the role is not inherited from anywhere and applied directly to this object, the field is empty.

Note

The roles may be either inherited from parent objects or applied directly to the current object. The groups/users that have directly applied roles on the selected task (object) are marked bold.

The role and its inheritance model can be edited only on the top parent object level, i.e., on the level where the role is applied directly.

The lower list of the Roles window displays the permissions for the group/user selected in the upper list.

7.4.1. Adding Groups/Users

Press the Add Groups/Users button to add a group/user to the upper list, then the dialog will appear:

_images/cerebro_perm_add_group.png

There is a button for creating a new group above the list of groups.

Note

Once you have configured the roles for the groups, you can manage the individual roles in a much simpler way – just by adding/excluding a certain user to/from an appropriate group. The group member inherits the access righs pattern from the group and, vice versa, when exluded, the access rights are discarded.

7.4.2. Editing the Access Rights

Pick the group/user whose access rights you want to edit, from the upper list in the Access Rights window. Then select an appropriate role from the dropdown list in the Role column (see ch. “Roles”). Then select the application area in the Applied To column (see ch. “Permission Inheritance”).

If the existing roles do not meet your requirements for a particular group/user, you can assign the best match and customize it by (un)checking necessary permissions in the lower list. This method is good for an exceptional, non-regular use. Otherwise, it is recommended to create a new role with the appropriate access rights pattern – press the Roles button to access the role edit window (see ch. “Roles”).

7.4.3. Discarding Access Rights

If you want to discard access rights of a group/user, pick the group/user in the list and press the Delete button or select None from the dropdown list of roles.

7.4.4. Discarding Inheritance

If, for some reason, you want to discard inherited access rights, uncheck the Include Inheritable Access Rights checkbox for the task selected.

As a result all the previously inherited rights will be marked as applied directly, and then discarded. After that you can edit local permissions for the task.

7.5. Configuring Global Access Rights

The global access rights are configured on the Administrator pane, on the Universe tab (see ch. “Universes”).

Switch to the Global Access Rights. This window looks similar to the one on the task level, with the only thing that differs: the access rights can be assigned only to groups, not to individual users.

7.6. Tips & Tricks On Configuring Access Rights

Keep things as simple as possible.

Avoid configuring roles and permissions for individual users, try to do it on the group level, when possible. It will help you keep the access management simple and predictable.

Configure access rights for an individual user by adding/removing the user account to/from the group with the appropriate role / access rights pattern.

Manage the access rights on the project level: select the root task in Navigator – it is the project level – and configure its properties. Specify roles for groups immediately when creating a new project. Add new users, that join your project along the way, to the approriate groups, and that’s it.

Avoid changing the access rights and discarding inheritance on the task levels lower than project, without necessity. If you need a more flexible configuration pattern than linear inheritance, use the conditional permissions and then allocate the users as assignees to particular tasks for the permissions to take local effect.

Remember: the simple you configure the access system - the easier it will be to use and maintain.