Permissions

The permissionRoot of a role describes what the role grants access to. This page explains how it is built up and how access is passed down to the parts below it. The Permission reference lists every part you can configure.

Structure

The permissions form a tree that follows the structure of the application: an FSP has dossiers, a dossier has bank accounts and documents, a document has assessments, and so on. Every node of the tree is called a namespace.

Each namespace can hold:

• a permissions object with the scopes granted on that namespace;
• sub-namespaces, one for each part below it.

{
  "fsp": {                       // namespace
    "dossier": {                 // sub-namespace
      "permissions": {           // scopes granted on "dossier"
        "read": {}
      },
      "bankAccount": {           // sub-namespace of "dossier"
        "permissions": {         // scopes granted on "bankAccount"
          "write": {}
        }
      }
    }
  }
}

The comments are only there to explain the example. JSON does not allow comments, so remove them when you copy it.

The top level of permissionRoot holds exactly one namespace and no permissions. Today, the only top-level namespace is fsp, which covers the FSP part of the application. A user gets such a role for one FSP, and it only gives access within that FSP.

Scopes

A scope is switched on by adding it with an empty object, e.g. "read": {}. Instead of the empty object, a scope can also hold filters that limit it to certain records.

Every scope allows one or more actions:

Scope	Actions
read	read
create	create
update	update
delete	delete
write	read, create, update and delete
all	Everything write allows, plus the actions of the extra scopes

Some namespaces have extra scopes for things that are specific to them, such as performCheck on due diligence or transition on dossier details. Each of them allows one extra action. all includes them; write does not.

A few namespaces do not support every standard scope. Document assessments, for example, can only be read and updated, so write and all only allow reading and updating there. The Permission reference shows the scopes of every namespace.

Inheritance

A scope granted on a namespace is also granted on all its sub-namespaces. Scopes granted lower in the tree are added on top. Take this role:

{
  "fsp": {
    "permissions": {
      "read": {}
    },
    "dossier": {
      "bankAccount": {
        "permissions": {
          "write": {}
        }
      }
    }
  }
}

The read scope on fsp is passed down to all its sub-namespaces, so the user can read dossiers, parties, documents, users and everything else in the FSP. On dossier bank accounts, the user has write as well and can also create, update and delete them.

Extra scopes only exist on the namespace that has them. all on fsp or dossier therefore does not let a user run due diligence checks; grant all or performCheck on the dueDiligence namespace for that.

No way to take access away

Permissions only add access. There is no way to remove on a sub-namespace what the namespace above it grants. If you grant write on dossier, the user can edit everything below it, including documents, due diligence and the RBA.

To give different access to a part and the parts below it, grant the scopes as low in the tree as you need. To make this possible, some namespaces come with special sub-namespaces:

• details holds the part itself and its own fields, without the parts below it. On a dossier, for example, details covers the dossier and its fields but not its bank accounts or documents.
• set holds access to the part together with the parts below it. See Combined access.

For example, full access to documents but read-only access to their assessments:

{
  "fsp": {
    "dossier": {
      "document": {
        "details": {
          "permissions": {
            "all": {}
          }
        },
        "assessment": {
          "permissions": {
            "read": {}
          }
        }
      }
    }
  }
}

Granting all on document instead would pass it down to assessment as well, and the read there would change nothing.

Combined access

Anything that reads or changes a record together with the parts below it is controlled by set, not by details. It does not matter whether it concerns one record or many: a screen that shows both the name of a dossier and its RBA result is controlled by set, even if it shows a single dossier.

Lists are the most common case. A list shows its records together with information from the parts below them, so it is controlled by read on set. A user who can read dossiers through details alone cannot open the dossier list. Grant read on the namespace itself, such as dossier (which is passed down to both details and set), or on set directly.

Actions that create or change a record together with the parts below it are controlled by set as well: creating, importing and exporting records, bulk actions, and filling in a record from an outside source such as an electronic identity card.

Deleting a record removes it together with everything below it, so it requires delete on set as well as on details. A record that is still in use elsewhere is not offered for deletion.

Several roles

A user who holds several roles gets the sum of all their permissions. A role cannot limit what another role grants.