- 4 minutes to read

Permission Set for the Repository Model

The following permissions exist for the Repository Model permission set:

graph LR subgraph "fal:fa-sitemap Permissions for Repository Model" ro23[fal:fa-lock Permission Set] --> ro1(fal:fa-door-open Global setting) subgraph "Repository" ro2(fal:fa-sitemap Access Repository) ro3[fal:fa-puzzle-piece Integrations] ro4[fal:fa-dice-d6 Systems] ro5[fal:fa-cog Services] ro6[fal:fa-file Message Types] ro7[fal:fa-sign-in-alt Endpoints] ro8[fal:fa-newspaper Knowledge base Articles] ro9[fal:fa-paint-roller Custom Fields] ro10[fal:fa-tags Custom Meta Data] end ro1 --- |Allow or Deny| ro2 ro1 -.- |Inherit, Allow or Deny|ro3 ro1 -.- |Inherit, Allow or Deny|ro4 ro1 -.- |Inherit, Allow or Deny|ro5 ro1 -.- |Inherit, Allow or Deny|ro6 ro1 -.- |Inherit, Allow or Deny|ro7 ro1 -.- |Inherit, Allow or Deny|ro8 ro1 -.- |Inherit, Allow or Deny|ro9 ro1 -.- |Inherit, Allow or Deny|ro10 end

A permission set is applied to the Roles level. The values for a permission are the following:

  • Inherited - default (which means not allowed, unless the end-user is part of another Role, where this grant is set)

    NOTE: Not allowed is NOT the same thing as a Deny(!) as it merely means; Honour the inheritance chain.

  • Allow - Access is granted.
  • Deny - Feature is blocked from usage. Use this setting only for special cases.

NOTE: Regardless of other permission sets, a Deny always win. Since the entities are assigned to the Roles, you should rarely have to use the Deny setting. Instead of denying access, consider removing the entity from the Roles instead.

For the Repository Model, the following operations are managed:

Access (read-only)

If the permission is set to Allow; The end-user has visibility and have read-only rights.

Create

If the permission is set to Allow; The end-user can create new items in the Repository Model for the selected entity.

Modify

If the permission is set to Allow; The end-user can modify existing items in the Repository Model for the selected entity.

Access Repository

To access and manage the Nodinite Repository Model; The User must be a member of a Roles granted (Allow) access to the Repository.

NOTE: If the User is a member of any Roles where access to the Repository is denied (Deny); Then the user is blocked access to the Repository Model.

Access right
The Roles is set to Allow access to the Repository.

If the Roles is denied access to the Nodinite Repository Model; The Repository is not even part of the main menu pane:
Unavailable Repository

Integrations

In the Web Client, for end-users in Roles where the Access Integrations permission is allowed; The end-user is granted the right to view information about Integrations. A Nodinite Administrator can manage the following permissions:

Managing Integrations
Example of managing the Integrations permissions for Role

Systems

In the Web Client, for end-users in Roles where the Access Systems permission is allowed; The end-user is granted the right to view information about Systems. A Nodinite Administrator can manage the following permissions:

Managing Systems
Example of managing the Systems permissions for Role

Services

In the Web Client, for end-users in Roles where the Access Services permission is allowed; The end-user is granted the right to view information about Systems. A Nodinite Administrator can manage the following permissions:

Managing Services
Example of managing the Services permissions for Role

Contracts

In the Web Client, for end-users in Roles where the Access Contracts permission is allowed; The end-user is granted the right to view information about Contracts. A Nodinite Administrator can manage the following permissions:

Managing Contracts
Example of managing the Contracts permissions for Role

The UseContracts System Parameter must be set to true; Otherwise, the Contracts feature is disabled.

Message Types

In the Web Client, for end-users in Roles where the Access Message Types permission is allowed; The end-user is granted the right to view information about Message Types. A Nodinite Administrator can manage the following permissions:

Managing Message Types
Example of managing the Message Types permissions for Role

Endpoints

In the Web Client, for end-users in Roles where the Access Endpoints permission is allowed; The end-user is granted the right to view information about Endpoints. A Nodinite Administrator can manage the following permissions:

Managing Endpoints
Example of managing the Endpoints permissions for Role

Articles

In the Web Client, for end-users in Roles where the Access Articles permission is allowed; The end-user is granted the right to view information about knowledge base Articles. A Nodinite Administrator can manage the following permissions:

Managing Articles
Example of managing the knowledge base Articles permissions for Role

Custom Fields

In the Web Client, for end-users in Roles where the Access Custom Fields permission is allowed; The end-user is granted the right to view information about Custom Fields. A Nodinite Administrator can manage the following permissions:

Managing Custom Fields
Example of managing the Custom Fields permissions for Role

Custom Meta Data

In the Web Client, for end-users in Roles where the Access Endpoints permission is allowed; The end-user is granted the right to view information about Custom Meta Data. A Nodinite Administrator can manage the following permissions:

Managing Custom Meta Data
Example of managing the Custom Meta Data permissions for Role


Next Step

Add or manage Role
Add or manage Log View
Add or manage Monitor View
Repository Model

Users
Log Views
Monitor Views
Access Management