Permission System

Tomas Jelinek edited this page May 8, 2016 · 1 revision

Since version 1.0 a new permission system has been introduced to kanbanik which allows to set the permissions up in a fine grained way as well as giving access to unlogged users.

Types of Users

There are 2 different types of users

  • regular user: meaning a user which has an account in kanbanik created
  • unlogged user: a special "abstract" user which represents anyone who is not logged in

There are the following differences between this two types of users: 1. It is not possible to log in as an "unlogged user" 2. It is not possible to delete the "unlogged user"

Other than that, this two types of users are completely equivalent. This means that the unlogged user can be given any permissions the regular user can have.


There are 2 types of permissions:

  • Creation: for example create board. This is a global type of permission (meaning this permission is not given on a particular object but globally per kanbanik). In case the create permission is given, the user which creates this entity is automatically assigned all permissions associated with this entity. So, for example, if the user is assigned permissions to create a new project, and the user will create a new project, this user will automatically be granted read, edit and delete project for this particular project.
  • Other: this are all other permissions (e.g. read, edit, delete, move tasks, edit user permissions etc). This permissions are always assigned on a particular entity (for example delete board assigned on a particular board)

For the "other" type of permissions there are 3 ways of assigning a permission to a particular entity:

  • Assign to one: The most simple one. For example a user is assigned to read one particular project.
  • Assign to all: A special permission. It is a kind of a wildcard where the user can be assigned a permission to for example see all boards. This applies to all boards which exists in the system today as well as for all which will exist in the system in future. For example the default "admin" user has by default all permissions assigned to this special "all" object.
  • Assign to couple: Since in kanbanik the base entity is not board but board+project (e.g. you can not move a task to a board, you need to move it to a project which is on a board) all task related permissions have to be assigned to project AND board. This way you can have for example one board serving as a template for the workflow and bunch of projects on it. Each user is than assigned to move tasks on particular combination of board + project.

Inheriting Permissions

Imagine this scenario: there are 2 users defined in the system: A and B. There is also a board B1 and project P1 and 2 class of services CoS1 and CoS2. On this B1+P1 there is a task on which the user B is the assignee and the CoS1 is set as the class of service.

Now, user A is assigned read board on B1 and read project on P1 but is not assigned read user on B and is not assigned to read CoS1. When he loads the B1+P1 he is allowed to see the task but not the assignee nor the class of service. If he would not inherit the permissions to see this user A and class of service CoS1 he would not see the correct state on the board.

The solution is that if the user has assigned read board and read project, he automatically inherits permissions to read everything what is on this board + project for the context of this board + project.