Please note: This is a highly experimental feature, available to administrators only and not supported for general usage. Handle with absolute care. By using this functionality, you acknowledge that by submitting a faulty query you not only risk to expose data to the public but also to destroy the entire database.

Another way to resolve permissions in a Structr system is to use Custom Permission Queries (CPQ).

A CPQ is a database query that determines whether or not a user or group (to be precise: any object of a type implementing the Principal interface) can access a given object with the requested permission.

By default, there are four different permission levels for object access: read, write, delete and access control. For each of these levels, one custom query can be defined, taking six (optional) parameters as input: principalId, principalUuid, principalType, targetNodeId, targetNodeUuid and targetType. If the query returns a boolean true value, the requested permission is granted, and not granted in any other case.

Please also note that CPQs are checked before any other method of permission resolution so it can be combined with other security settings. This may have unexpected results if you’re not aware of this fact.



A user or group has the following Cypher query set for the read permission (please note that the Cypher parameter in the inner {} must not be written with surrounding ""):

MATCH (p:Principal {id: {principalUuid}}) -[h:HAS_PERMISSION {name: "read"}]->(s:SchemaNode {name: {targetNodeType}}) RETURN h IS NOT NULL

Translated into human language: Grant the read permission if a relationship exists between the user or group and the schema node with the same name as the target node’s type.

Example for creating relationships like this:

MATCH (p:Principal {id: "37b1731979e649cb9d79eebf2b9e0256"}), (s:SchemaNode {name: "Project"}) CREATE (p)-[h:HAS_PERMISSION {name: "read"}]->(s)


About this article
Last change 2018-07-30