Project folders and permission roles
Tutorials and guides for the features of Octaved Flow
In Octaved Flow, projects can be organized in project folders. The top level is the company or organization and is named as you specified when activating the Octaved Flow demo. For example My company GmbH.
The project folders below My company GmbH can, for example, be departments or business units of My company GmbH. It would also be possible to create a folder for each customer or for specific customer groups. The principle is completely flexible.
The idea for project folders is similar to a file system ("drive"), where there are folders and files. Folders correspond to project folders, files to projects. Just as a system administrator typically assigns permissions for folders - and not for individual files - in Windows, permissions are assigned for project folders in Octaved Flow in the same way. It is best to set up the structure of the project folders in such a way that permissions can be administered conveniently and with minimal subsequent maintenance effort.
It is perfectly legitimate to dispense with project folders and only have all projects at the top level My company GmbH. All permissions are then administered at this level. If you have no idea how to organize your projects in project folders, then just leave it as it is. You can also do it later and then reorganize your projects. Then simply work with the only project folder that exists, the My company GmbH folder.
Users receive rights to a project folder by being assigned an permission role for this project folder. This applies to both users and groups of users.
Depending on the license level, project folders may or may not be visible to you. In the basic license, you only have one superordinate level in which you can organize your projects and assign authorization roles.
The permission roles are:
- Reader - Users with this permission role can see everything in the projects, but cannot edit anything.
- Standard - Users with this permission role can do everything they need to do to complete work packages. This includes, for example, marking work packages as completed, creating and checking off tasks, writing board posts and tracking times in projects. The Standard permission role cannot be used to perform actions that are reserved for project managers and department heads. It is not possible to create and delete projects and work packages, view prices, edit commercial details such as maximum effort, assign responsible persons, plan work packages and change their planning.
- Full - The Full permission role contains all permissions for projects, sub-projects and work packages. It is usually assigned to project managers, department heads and managing directors.
- None - This permission role cancels an inherited permission role. Users with this permission role have no access.
As you can see, the permission roles are in ascending order from None to Full.
The permissions are additive, or in other words "higher wins". If someone has the Standard permission role for a project folder as a member of a group and the Full permission role as an individual user, then Full wins. In case of doubt, the higher permission role always wins.
Briefly summarized once again: On a project folder, a user (or a group of users) is assigned one of the permission roles None, Reader, Standard or Full.
This setting then applies to all projects in the project folder and controls the user's rights for the folder and all contained projects.
The permission role that a user has been assigned via project folders cannot be reduced or removed in a project.
Good to know
Project managers and responsible users
The users involved in a project can be divided into project managers and responsible users. Project managers manage projects. For example, they create work packages for a project and plan the project process. Responsible users implement the work packages assigned to them by the project manager. The terms are not firmly defined here; a team leader can also be what is referred to as a project manager in Octaved Flow.
A project manager must of course have more rights than someone who is only responsible.
Rights upgrade
And there is another useful effect: there is a connection between project roles and permission roles. This is best illustrated using an example.
Let's assume that a user in the project folder only has the permission role Reader. They therefore only have the right to read all projects and work packages. If this user is now assigned to a work package as the person responsible, they would not have sufficient rights to actually be able to work on this work package. For example, the user would not be able to write anything on the board, track any times or mark the work package as completed.
Of course, you could give the user the Standard permission role for this work package, which would make all this possible. But wouldn't that be far too much administrative effort? That's why Octaved Flow has an automatic "upgrade" of permission roles instead, either when a user is assigned as a responsible person or when a user is assigned to a work package via a project role with the additional permission role Standard. In this way, they automatically receive an upgrade to the Standard permission role for this work package, although they actually only have the Reader permission role on the project folder.
A project role of the type Project manager
Good to know
If you have the permission role None on the project folder, then it is not possible to access the work package. The reason is obvious: If you can't even see the project folder, you can't get any further. So if you give a user the permission role None for a project folder, then you should be sure that the user will have nothing to do with these projects. Incidentally, this procedure is helpful if you want to set up a client system because, for example, there are two independent business units in your company. But back to the actual topic!
In summary, all you need to do is create project roles according to your requirements, if necessary, and assign a corresponding permission role to each project role. Then you just need to assign users with their respective project role to the work package or add users as responsible and Octaved Flow will do the rest automatically.
Best practice for project roles and permission roles
The points described in this section are only an initial guide and are intended for better understanding. There are many "right" ways to set up an authorization system.
Project managers are usually assigned the permission role Full at folder level. This is necessary so that they can create projects at all. This is also useful so that a project manager can stand in for a project manager colleague on vacation or sick leave without having to make any adjustments to the authorization system.
The responsible users receive either the permission role Reader or Standard on project folders and are assigned to the respective work packages as Responsible.
A sub-project manager can receive a project role of the type Project manager for a group (of work packages) and thus manage a part of the project.
Project roles and permission roles summarized in comparison
Permission roles define what a user is allowed to do. Project roles define which function or role you have in the project.
The project role shows external responsibility. If others see that I have the project manager project role for a project, they know that they can contact me if they have any questions about this project.
The situation where a user has the responsibility for a project but not the permission to fulfill the responsibility is solved in Octaved Flow via the permission upgrade. If you have less permission than responsibility, you automatically receive the appropriate upgrade.
Project folders and inheritance
The inheritance of rights in folder structures is an advanced technique that is a standard procedure for system administrators and is often used.
The permission roles set for a project folder are automatically inherited by all project folders below this project folder. The inherited permission roles can be removed, reduced or extended on the project subfolder.
An inherited permission role is simply overwritten by another one. To remove, overwrite with the permission role None. Inheritance is indicated by colors when editing. Overwritten permission roles are displayed in blue.
Additional users or groups with permission roles can also be added. Entries added to a project folder are displayed in green when editing.
