Rights, roles, and permissions

Tutorials and guides for the features of Octaved Flow

When you try Octaved Flow, you and everyone you invite to test it will initially have all permissions available in Octaved Flow. This makes sense, too, because it allows everyone to experience the full functionality of Octaved Flow. So every user you invite to Octaved Flow is an administrator.

If you use Octaved Flow productively, you probably won't want all users to be administrators, and will set permissions in more detail. For small teams that don't use permissions in other ways either, the "everyone gets to do everything" principle may be just fine. If you want to use permissions in Octaved Flow, which is usually safe to assume, then this tutorial is for you.

Octaved Flow's permissions concept is very flexible and suits the needs of small, medium and very large companies and organizations. Regardless of what software you are looking at, if a feature in software is very flexible, it is rarely self-explanatory.

Fortunately, despite being very flexible, the permissions features in Octaved Flow are not really complicated to use once you understand a few basic terms and concepts. System administrators will find their way around right away, because Octaved Flow integrates many well-known and proven concepts. The interrelationships are explained in this tutorial in a way that is understandable and comprehensible for everyone.

Project Managers and Executors

In principle, the people involved in a project can be divided into project managers and executors. Project managers manage projects, e.g. they create work packages for a project and plan the project schedule. Executors implement the work packages assigned to them by the project manager. The terms here are not fixed, a team leader can be just as what is called a project manager in Octaved Flow.

Someone who is a project manager obviously must have more rights than someone who is an executor.

Project folders and permission roles

In Octaved Flow, projects can be organized into project folders. The topmost level is the company or organization and named as you specified when you activated the Octaved Flow demo. For example, "My Company Ltd".

The project folders below My Company Ltd. can be, for example, departments or business units of My Company Ltd. In the same way it would be possible to create a folder for each customer or for certain groups of customers. 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 in Windows a system administrator typically assigns permissions for folders - and not for individual files - analogously permissions in Octaved Flow are assigned for project folders. It is best to build the structure of project folders in such a way that permissions can be administered conveniently and with minimal subsequent maintenance.

It is perfectly legitimate to do without project folders and to have all projects only in the top level "My company Ltd". Then all permissions are administered on this top level. If you have no idea how to organize your projects in project folders, then just leave it as it is. You can also catch up later and rearrange your projects then. Then just work with the only project folder there is, the folder "My Company Ltd."

Users get rights on a project folder by assigning them a permission role for that project folder. This applies to users as well as groups of users.

Depending on the license level, project folders may or may not be visible to you. In the basic license, you have only one superordinate level in which you can organize your projects and assign authorization roles.

The permission roles are:

None - a user with this permission role will not be able to see any of the projects in the folder, he will not even know about the existence of the folder itself. In Octaved Flow, this permission role is displayed as three hyphens (---).
Reader - Whoever has this project role can view projects and work packages, but cannot do anything with them. Copying work packages works, by the way, but only to another location.
Standard - With this permission role, you can view projects and work packages, create tasks for work packages, post items to the wiki, and post project work time to work packages. So this permission role is for executors. There is a good reason why the permission role has a different name. More on that later.
Manager - Whoever has this permission role is allowed to do everything Standard is allowed to do, plus create projects and work packages, and see and edit prices (when Octaved Flow is used for customer projects). So this permission role is obviously for project managers. Again, the name of the project role is intentionally not Project Manager, but (abbreviated) Manager.
Project Folder Administrator - This permission role is allowed to do everything the Manager is allowed to do and additionally administer the permission roles for project folders.

As you can see, the permission roles are in ascending order from None to Project Folder Administrator. A tabular overview of exactly what permissions are behind the permission roles is later in this tutorial.

The permissions are additive, or in other words "higher sticks". If someone has the permission role Standard as a member of a group for a project folder and the permission role Manager as an individual user, then Manager wins. In case of doubt, the higher permission role always wins.

Once again briefly summarized: On a project folder, a user (or group of users) is given one of the authorization roles None, Reader, Standard, Manager or Project folder administrator.

This setting then applies to all projects in the project folder and controls the user's permissions for the folder and all contained projects.

In a project, the permission role that a user has been given via project folder cannot be reduced or taken away in a project.

Work packages and project roles

A user can be a project manager or an executor. Project manager and executor are so called project roles in Octaved Flow.

To be more flexible, Octaved Flow adds another layer. You can create project roles according to your requirements and also create as many project roles as you need. In order for Octaved Flow to "know" what is meant by your project role, there are the project role types. Admittedly, this is a bulky word, but the idea behind it makes a lot of things easier.

There are essentially two project role types, and they are Project Manager and Executing. So you can name your project role Scrum Master, for example, and give it the project role type Project Manager. Or you can just name the project role PM and give it the project role type Project Manager. In the default configuration of Octaved Flow, there is a project role Project Manager with the project role type Project Manager. This may sound confusing at first, but now you know what is meant.

What does the project role type do? It is quite simple. If a user has a project role of type Executing for a work package, then this work package will be displayed in the user's workspace as "to be edited", regardless of what the project role is actually called. It only needs to be of type Executing. Project managers do not see the work package in their workspace, after all they are not supposed to implement it themselves. Executors always see who the responsible project manager is.

Rights upgrade

And there is another useful effect: namely, there is a connection between project roles and authorization roles. This is best illustrated with an example. Let's assume that a user in the project folder has the Read permission role. This means that the user only has the right to read all projects and work packages. If this user is now assigned a work package as an executor, he would not have sufficient rights to actually be able to take action on this work package. For example, the user would not be able to write anything on the board, book any times, or mark the work package as completed.

Of course, one could give the user the authorization role default for exactly this work package, with which all this would be possible. But wouldn't that be too much administrative effort? That's why there is an automatic "upgrade" of permission roles in Octaved Flow instead. If a user has a project role as executor, he automatically gets an upgrade to the authorization role Standard for this work package.

The context is as follows: With a project role of type Executor, one receives an upgrade to the authorization role Standard. With a project role of the type Project manager you get an upgrade to the authorization role Manager. For the upgrade it doesn't matter which authorization role the user had before. And it doesn't matter what project role designations are common in your company or organization. Anyone with too few permissions to perform the assigned project role simply gets an upgrade.

If one has the permission role None on the project folder, then it is not possible to get to the work package. The reason is obvious: if you can't even see the project folder, then you can't get anywhere. 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. By the way, this procedure is helpful if you want to set up a multi-client system, for example because there are two independent business units in your company. But back to the actual topic!

So, in summary, all you have to do is the following: create project roles according to your requirements, if necessary, and assign each project role either the project role type Executing or Project Manager. Then you just need to assign users with their respective project role to the work package and Octaved Flow will do the rest automatically.

Best practice for project roles and permission roles

The points described in this section are only a first guide and meant for better understanding. There are many "right" ways to build an authorization system.

Project managers are usually given the Manager permission role at the folder level. This is necessary for them to be able to create projects in the first place. This is also useful so that a project manager can substitute for a project manager colleague in case of vacation or illness without the need for adjustments to the authorization system.

Executors are given either the Reader or Standard authorization role on project folders. For the respective work package, executors are then assigned a role of the project role type Executing.

A subproject manager can get a project role of type Project Manager for a group (of work packages) and thus manage a part of the project.

Project roles and authorization roles in summary comparison

Authorization roles define what a user is allowed to do. Project roles define what function or role one has in the project.

The project role shows the responsibility to the outside world. If others see that I have the project role Project Manager for a project, they know they can contact me with questions about that project.

The situation where a user has accountability for a project, but does not have the permission to also fill the responsibility, is solved in Octaved Flow via the permissions upgrade. If you have less permission than responsibility, you will automatically get the appropriate upgrade.

Menu item "Permissions" in the system settings

In the system settings in the menu item Permissions permissions are set, which apply either globally or for the system settings itself - in any case independent of project folders.

The logic here is that users are added to the functions, giving them the appropriate permission. The functions are:

Administrator - This is the (global) administrator in Octaved Flow who has all permissions. This includes all system settings and all project folders. The administrator is not allowed to delete themselves or take away the administrator role.
Administrator System Settings (Commercial) - Users with this role are allowed to edit the following in the system settings: Price Categories, Customers
Administrator System Settings (Advanced) - Users with this role are allowed to edit the following in the system settings: Price categories, Customers, Labels, General, Project roles, Project folders, Timeout. There are more functions in the table. The explanation of each entry is displayed on the right when you click on the entry.

In this menu item in the system settings you can also define who is allowed to see whose time bookings.

See time booking list

If you do not use Octaved Flow's project time booking, you can skip this section.

Project time booking is a sensitive issue in many companies and organizations. When it comes to others being able to see what you have done during the day, it crosses a red line for some.

In Octaved Flow, everyone can decide for themselves who is allowed to see their own time bookings and also take away this possibility from someone else. This can also be defined centrally by the administrator via the menu item Permissions in the system settings.

Ultimately, it is about a matrix of all users, in which it is specified who may see whose time bookings. What are the effects of being allowed or not allowed to see the time bookings of others?

The setting that user A is not allowed to see B's time entries has two effects. First, user A sees B's time bookings only anonymously in the context of work packages. A can see all time bookings for a work package and that makes sense. Because the activity descriptions in the time booking can be very helpful, for example when one takes over a work package or continues to work on it. Also, you might want to copy time entries so that it is more consistent to the customer. But A doesn't see B's name in the time booking.

As a user, if I don't have at least the Reader permission role for a work package, I can't see time entries for that work package in any case, anywhere in Octaved Flow. What permissions do I need as a user to see time postings?

I am allowed to see a time booking anonymously if:

I have at least the Reader permission role for the work package.

I am additionally allowed to see the name of the person who made the booking, if:

I have at least the authorization role Manager for the work package, so I am usually the project manager of the project - or
In the system settings under permissions it has been set that everyone is allowed to see the time bookings of everyone - or
The other user has given me the right to see his time bookings via the time booking matrix or the administrator has configured it this way in the system settings.

Whoever has the authorization role Manager for a project, i.e. is a project manager, can always see all time bookings in the project by name, in order to be able to clarify any questions or discrepancies.

In Octaved Flow there is a list of all time bookings per day. Here you can add team colleagues. In the described case, however, A cannot add B to this overview, not even anonymously.

By default, Octaved Flow is set to allow everyone to see everyone's time bookings.

Groups of users

Users can be grouped into user groups. A user can be in any number of groups.

The idea of groups is to save clicks. If you want to add the same users in multiple places to set permissions, it is worth creating a group for those users. Then instead of adding multiple users, you only need to add one group.

Groups can also be used in meeting time postings. You can mention a group in a post in the wiki to mention all members of the group about the post. Again, the group saves clicks.

Preparing for production use

Create groups of users, if necessary.
Create your own project roles or use the existing ones.
Create project folders or work with only one project folder Meine Firma GmbH.
Assign permission roles for users or groups on the project folders. Don't forget that at least one must be (project) manager to be able to create projects in the project folder at all.
Add users or groups to the functions in the Permissions menu item in the system settings.
Remove the setting that every new user is administrator

A new user becomes an administrator by default as follows: Every new user is automatically assigned to the (user) group All. The All group is assigned to (global) Administrator in the Permissions menu item. So every new user becomes an administrator. Simply remove the group All from Administrator. This will break the automatic, new users will not become administrator and existing ones will not be administrator anymore.

You must not remove yourself from being an administrator. If you are an administrator only through the All group (which is the case in the Octaved Flow demo), just apply a little trick. Add yourself to the administrators. Then they are double assigned, but that is exactly what you want. After that, you can remove the All group from the administrators.

System administrators usually don't work with full rights as system administrator all the time. They have their own user account, which does not have administrator rights. They log in as administrator only when there is something to administrate and log out right after that. Sometimes it is recommended to have two administrator accounts. If there is a problem with the first administrator account, such as "forgot password", then it can be reset via the second administrator account.

An administrator account counts as a regular user and requires a license of Octaved Flow.

Project folders and inheritance

Inheritance of permissions in folder structures is an advanced technique that is a standard procedure for system administrators and is often used.

Permission roles set for a project folder automatically inherit to all project folders below that project folder. The inherited permission roles can be removed, reduced, or extended on the project subfolder.

An inherited authorization role is simply overwritten by another one. To remove, overwrite with the authorization role ---. When editing, the inheritance is indicated by colors. Overwritten authorization roles are displayed in orange.

In addition, further users or groups with authorization roles can be added. Entries added to a project folder are displayed in green when editing.