Permissions system in KnowledgeTree 3

Also since (internal release) 2.0.8, KnowledgeTree supports a rich permissions system. The backend can handle permissions on a per-document and per-user level, inherited or not, and with dynamic permissions (such as because of local roles) handled efficiently, even for searches.

Pre-2.0.8, KnowledgeTree had a reasonably simple permissions system. Basically, groups are assigned read or write permissions on a folder, and folders either have their own permissions set on them, or they inherit from their parents.

Here is what it looked like:

The permissions-related requirements from the contracting customer were twofold: Add a "Add Folder" permission, and add the ability to assign permissions to a group only on documents that contain certain metadata. We asked whether we should just tack on "Add Folder" or make the whole system extensible, and were delighted that the latter was chosen.

Let's start with the end result - this is what that screen looks like now:

At the top, you can see how the permissions have been assigned to the folder. Below that, you can see how these permission assignments on the folder affect every user's permissions on the folder.

This is the new (improved?) interface for assigning permissions. As you can see, the "Add Folder" permission has been added.

Permissions can now be arbitrarily created by the administrator of the KnowledgeTree instance. So, in a similar way to how we added "Add Folder", a plugin can create a permission and have it be handled like all the other permissions in the system:

One thing that isn't exposed in the user interface yet is that there really is nothing preventing permissions being assigned to users directly (not via groups). Nor is there anything preventing location-specific roles from being created and assigned permissions. And also not obvious is how permission assignment subject to metadata conditions are handled.

Quite simply, the assignment of permissions we see above describe the "static" set of permissions assigned to the object. The "Permission Object" knows only about the direct assignments on the object. In itself, it has no idea what the effects of adding a permission for a group are in terms of the users that have access.

There is a separate lookup function that maps the assignment of all permissions in the system to users and groups (groups are never expanded). In the generation of the lookup, "dynamic" permissions that rely on metadata conditions succeed or fail on the particular object, or roles are replaced with the particular groups or users that hold that role in that location.

To put it simply - the permission assignment is the top part of the permissions screen where permissions are assigned to the object. The lookup is the bottom half - checking each user for a particular permission on the object.

Of course, one could do the lookup at runtime rather than store it directly. But that makes many operations highly inefficient. The simplest of these is "give me the list of documents in this folder that the user can read". While inefficient, this is survivable (it is what KT did pre-2.0.8). The real crunch comes down to searches. You can't afford to check whether the user has access to a document after you've got a bunch of documents outside of your database query.

To make this remotely storage-efficient, an indirection called "descriptor" is used. A descriptor uniquely identifies a particular set of groups, users, and roles in the assignment case, and just groups and users in the lookup case. In other words, whenever groups A and B and user C have permissions on an object, they will share a descriptor. This prevents having to have a table which goes [ document_id, permission_id, user_id], having number of documents * number of permissions * numbers of users as its upper size.