Permissions - dotProject Roles

From DotProjectWiki

Jump to: navigation, search

PERMISSIONS LINKS

User Roles are standard groupings of permissions that can then be applied to user's as required.

Roles are applied by a user with special permission to access that functionality, but general users can see the roles they have been granted via MyInfo > Permissions and Role Tabs.

This page, however, explains how roles are generated. You should also ensure that you read and understand Permissions - Known Limitations before you start setting up your roles.

Contents

1 Creating User Roles

Roles are created via the System Admin > User Roles link.

This screen lists all existing roles in your system in the columns:

Icon Column The first column is broken down into 3 icons.
  • Edit icon - click on that to edit the existing role ID and description
  • Padlock Icon - click on that to change the permissions matrix for the role
  • Trashcan Icon - click on that to delete the role[1]
Role ID Short name of the role
Description Full description of the role

To create a role simply enter an ID and a description and click on the Add button. Once the role is in the main listing, use the Padlock icon to set up the required permissions matrix.

To create that matrix:

  • Select the relevant module (or group of modules).
  • Select the option required (allow or deny), then select the permission types that the option will relate to.

2 Understanding Roles

To understand roles further, let's look at a couple of the roles which are distributed as defaults with dotProject.

2.1 Project Worker

Non-Admin Modules
Access Allow
View Allow
Edit Allow
Add Allow
Delete Allow

This role basically means that any assigned user can access all of the Non-Administration - see ACLs in dotProject. We'll look at how you can further modify that role in Permissions - Modifying Roles at the User.

We'll also discuss modifying the Project Worker role further in Permissions - Examples of Permission Setups

2.2 System Admin

Admin Modules
Access Allow
View Allow
Edit Allow
Add Allow
Delete Allow

This role basically means that any assigned user can access all of the Modules - see ACLs in dotProject.

Those are both pretty simple examples, so let's look at a couple of other old standards now.

2.3 Project Worker, No Help Desk Add on Module Access

In this example we've taken a hypothetical system with the Help Desk Module installed, but not made generally available:

Non-Admin Modules Help Desk Addon
Access Allow Deny
View Allow
Edit Allow
Add Allow
Delete Allow

This role would mean that any assigned user would not even see the Help Desk module on the menu.

2.4 Guest User

In this example we've taken a hypothetical system that is allowing a guest login, who will be able to see projects, tasks and calendar entries.

Projects Tasks Calendar
Access Allow Allow Allow
View Allow Allow Allow
Edit
Add
Delete

This role would mean that any assigned user would be able to see the 3 nominated modules (and records within those modules, but would not be able to add / change any of the records).

If we wanted to restrict that guest to seeing only projects relating to their own company or maybe a specific project, then we would adjust the permission at the User / Permissions level - see Permissions - Modifying Roles at the User and Permissions - Known Limitations which will explain some of the intricacies in dependencies.

NOTE: Even if we want to restrict access at a company level, we don't need to turn on access to the company module itself within the role. You would only allow any of the permission types to the Company module if you wanted the user to use the actual module.

3 Return to...

...back to Permissions

4 Footnotes

  1. ? If you have users who have that role assigned to them then the role will still be deleted with no warning
Personal tools
System Administration
Conversion