Permissions - dotProject Roles
From DotProjectWiki
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.
|
| 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...
4 Footnotes
- ? If you have users who have that role assigned to them then the role will still be deleted with no warning
