Home > Engine & Repository

Permissions

Permissions specify and regulate the access of each user to Master Data and the actions he can execute.


Principles overview

Permissions, Users, Roles and Profiles

Permissions are related to actions (action authorized or not) and to access rights (hidden, read, read-write). The main entities controlled by permissions are:

The definition and the resolution of permissions make extensive use of the profile notion, a generic term that references either a user or a role. Each user can participate in several roles and a role can be shared by several users.

A permission rule defines the authorization granted to a profile on an entity. Two kinds of permission rules exists:

See also :

Resolution of Permissions and Restriction Policy

Permissions are always resolved in the context of an authenticated user session. Hence, the defined permission rules will be able to take into account the information associated with the current user, more particularly the roles in which he participates.

When defining a permission rule, you can activate a restriction policy for the rule. Restriction policy is used to give a greater priority to rights defined in a rule.

See also:

Defining permissions with EBX.Manager

As described below, each level has a similar schema that allows the definition of several permission rules of type: "To a given profile, given permissions". Following sections will demonstrate how to define permissions using EBX.Manager.

Permissions on a branch

For a given branch, several permission rules can be specified. For each defined profile, you will be able to define permissions for the branch and its child.

On the branch page, select the link "Access right":

This link gives access to the following table:

This table presents permissions for the current branch. The button , on this table, allows to add a permission for a given profile in a page similar to the one illustrated thereafter:

The first section, "A" in the figure above, allows to define an access right on the current branch and also possible actions. The second section, "B" in the figure above, allows to define authorized actions on a child branch created by this profile. For example, the owner of the current branch gives profile X permission to access the branch and to create a child branch. Actions allowed for profile X, on the branch he will create, are defined in section "B".

See also : Permissions meaning for branches

Permissions on adaptation instance

For a given adaptation instance above an (included) agreement, several permission rules can be specified. For each defined profile, you will be able to define permissions for the adaptation instance.

In an instance, the "Permissions" tab allows to access the adaptation instance permissions page:

A first edition page for permissions on adaptation instance appears with the link "Access Rights by Profile" for editing a given profile permissions ( cf. figure below):

Afterwards, a second page allows to create instance permissions. For that, you have to click on the button . This page also allows existing permissions modification by users having the right to do so:

Permissions edition page on instance is illustrated below:

The previous page allows to edit actions on instance (create a child adaptation, manage agreement, etc). It also allows to edit default actions on tables and default access rights on nodes.

This page will also allow to define specific permissions policy for tables or nodes.

See also : Permissions meaning for adaptation instances

Specific permissions on nodes

For table nodes , different actions can be defined (create a record, hide a record, etc.) by clicking on the corresponding link "Add an occurrence". A list of actions, similar to the following, then appears:

For all nodes (including table nodes), access rights are defined by selecting the target node in the list (see figure below) and, afterwards, by clicking on the corresponding access right link (ReadOnly, ReadWrite, Hidden or default). The given node is then displayed with its corresponding access right. Hence, one can define an access right for each node of the adaptation instance ( see figure below ):

Specific permissions on services

Specific permissions on services allow to enable or disable a service ( see figure below ):

By default, all services are enabled. To disable or enable a service, you only have to click on the corresponding service label in the services list. The service label is greyed and crossed when it is disabled.

Home > Engine & Repository