Permissions

Permissions are used to restrict user access and actions:

On the server side, to prohibit the execution of an API (of an entity view or a server method).
On the client side, to restrict access to UI views and visibility of actions.

They are not directly tied to resources but to functions.

A function is used to group Neos resources under a functional name.

Functions

A function is conceptualized with the following properties:

Name: The unique name of the function.
Caption: The caption of the function.
Permission type: The type of permission associated to the function.
- Allow/Deny: The resource(s) will be authorized or denied.
- CRUD: The operations of creation, reading, update or deletion on the resource(s) will be allowed or denied.
Authorization condition: The C# condition to determine whether a function is authorized according to a business option.
Authorization visibility condition: The C# condition to determine whether a function is displayed in the functions tree (see remarks).
Documentation: The documentation that will be displayed on the permission assignment screen (e.g. to explain the authorization condition).
Module: The module of the function.
Resources: The collection of resources associated with the function.

Tree of functions

The functions are built as a tree in Neos Studio.

This means that a function can have sub-functions: If the user does not have permissions for a function, he will not have permissions for the sub-functions as well.

Unlike other metadata, the function tree design screen is global to the cluster and not per module. Despite this, a function is still linked to a module. This implies that the module of a sub-function must be the module of the parent function or a child module of the parent function's module.

Resources

The resources that can be associated with the functions are the following:

Entity
Entity view
UI view
UI view action
Server method
Menu item that executes code

The resources inherit the functions of the parent resources:

If an entity is linked to a function, the entity views that are based on that entity as well as the UI views that are based on those entity views will be impacted by the permissions related to the entity's function.
If an entity view is linked to a function, the UI views that are based on this entity view will be impacted by the permissions linked to the entity's function.
A menu items that open a UI view will be affected by the permissions linked to the UI view's function.

Even though it is not recommended, a resource can be associated to several functions:

When a resource is associated to several Allow/Deny functions, the resource will be authorized if at least one function is allowed.
When a resource is associated to several CRUD functions, the authorized operations will be merged. For example, reading on the first function and reading and updating on the second, the resource will be readable and updatable.

When a resource is associated to a Allow/Deny function and a CRUD function, the permissions are calculated in this way:

Allow/Deny function	CRUD function	Permissions
Allow 🟢	Full allow 🟢	Full allow 🟢
Allow 🟢	Full deny 🔴	Full allow 🟢
Allow 🟢	Read only 🟠	Full allow 🟢
Allow 🟢	Unset	Full allow 🟢
Deny 🔴	Full allow 🟢	Full allow 🟢
Deny 🔴	Full deny 🔴	Full deny 🔴
Deny 🔴	Read only 🟠	Read only 🟠
Deny 🔴	Unset	Full deny 🔴
Unset	Full allow 🟢	Allow (CRUD) 🟢
Unset	Full deny 🔴	Full deny 🔴
Unset	Read only 🟠	Read only 🟠
Unset	Unset	Full deny 🔴

Also, in Neos Studio, there is a screen that lists the resources not associated with a function.

Get permissions by code

Since version 2.0, you can obtain function and resource permissions via server-side C# code:

To obtain function permissions, you must use the IFunctionAuthorizer service.
To obtain resource permissions, you can use the IFunctionResourceAuthorizer service.

Since version 2.1, you can obtain permissions via client-side C# code:

From a ViewModel, you can use the method GetPermissions to get an object allowing you to know the permissions of the current UI view.
From anywhere in the code, you can use the static method Permissions.GetForUIView to get an object allowing you to know the permissions of the specified UI view.

Licensing

Since version 2.2, the License Management cluster influences permissions.

First-level functions can be associated with a license.

If the tenant has a license with associated functions, only these will be visible in the tree and can be authorized for the tenant's users. On the other hand, functions that are not listed will not be visible in the tree and will be forbidden for all tenant users.

If the tenant has no license or a license with no associated functions, nothing changes.

Remarks

Authorization visibility condition

Being able to set the "Authorization visibility condition" is useful

when the function is technical and that the "Authorization condition" is exclusively set for non-client (e.g. publishers)
when the function is not used (e.g. provided by a module, deprecated, or in development)

In such cases, the function (and its associated permission status) can be hidden from some or all users.

Table of Contents