Skip to main content

Permissions

ADITO permissions control whether users can see data, read it, or modify it. In most projects, permissions are configured through the client-based authorization model in User Administration > Contexts. Additional permission-dependent behavior can be implemented in JDito where required.

Scope of permissions​

Permissions are evaluated for Entities and related elements such as fields or actions. They are not assigned to Views directly.

This distinction is important for UI behavior:

  • Data permissions determine whether records or fields can be read or modified.
  • Element visibility determines whether referenced content is shown in the client.
  • Tabs and drawers derive their visibility from the visibility of their contained references, not from a dedicated tab permission.

For a description of how this affects tabs and drawers, see Further design elements.

Permission types​

The following permission types are the most relevant in day-to-day customization work:

PermissionPurposeTypical effect
VIEWControls whether an element is visible at all.Referenced UI content can disappear completely. This can also make a tab disappear when all relevant referenced content is invisible.
READControls whether data of an Entity can be read.Users may see less or no data, but the viewtemplate does not automatically disappear just because READ is missing.
CREATEControls whether new records can be created.Create actions or editable UI paths may be disabled or hidden, depending on the component.
UPDATEControls whether existing records can be changed.Edit actions or editable fields may become unavailable.
DELETEControls whether existing records can be deleted.Delete actions may become unavailable.
note

VIEW and READ are often confused, but they solve different problems. VIEW affects visibility. READ affects data access.

Prefer the client-based permission model whenever possible. It is the standard approach for most business applications and should be the default choice for role-based access control.

Use programmable grants such as grantCreate, grantUpdate, or grantDelete only when the required rule cannot be expressed cleanly through the client configuration.

Typical reasons for programmable grants are:

  • The rule is global and should apply independently of role configuration.
  • The condition depends on logic that is difficult to model declaratively.
  • The permission must be enforced in a particularly strict or sensitive scenario.

For performance-related recommendations, see Performance Optimization for Entities.

Permission-dependent UI behavior​

If the default visibility behavior is not sufficient, implement the desired UI reaction explicitly in a stateProcess.

Typical examples are:

  • Hiding a tab only when a user has neither visible content nor the required permission-dependent access.
  • Disabling an action when a condition and a permission must both be satisfied.
  • Showing or hiding helper fields depending on the current permission context.

When implementing such logic, do not rebuild the permission model manually. Use the JDito API instead.

if (tools.hasPermission(tools.PERMISSION_VIEW, "Person_entity")) {
  result.string(neon.COMPONENTSTATE_AUTO);
} else {
  result.string(neon.COMPONENTSTATE_HIDDEN);
}

The method also supports checks for tools.PERMISSION_READ, tools.PERMISSION_CREATE, tools.PERMISSION_UPDATE, and tools.PERMISSION_DELETE.

tip

Use tools.hasPermission when your JDito logic depends on permissions. This keeps UI logic aligned with the configured permission model.