Home > Engine & Repository

Permissions

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

Main principles

Specification of Permissions

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

  • branches,
  • adaptation instances,
  • tables,
  • terminal nodes (which hold Master Data values)

Permissions can be specified in two ways:

Resolution of Permissions

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

The resolution process is further detailed in chapter Resolution of permissions.

Note: From Java environment, the class SessionPermissions provides access to the resolved permissions.

Users, Roles and Profiles

The definition and the resolution of permissions use largely 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. These informations are defined by webMethods MDM Directory.

Particular definitions:

  • A user is an administrator when he participates in the built-in role ADMINISTRATOR.
  • A user is an owner of an instance when he participates in the "owner" attribute specified on the root instance ("Infos" tab). In this case, the built-in role OWNER is activated when permissions are resolved in the context of the instance.
  • A user is an owner of a branch when he participates in the "owner" attribute specified on the branch. In this case, the built-in role OWNER is activated when permissions are resolved in the context of the branch.
  • A user is a distributor of an agreement (or of an instance under the agreement), when he participates in the "distributor" attribute specified on the agreement ("Infos" tab). In this case, the built-in role DISTRIBUTOR is activated when permissions are resolved in the context of the instance.

Particular privileges on instances

For a specific adaptation instance, the following tasks are accessible only if the user is an administrator or an owner of this instance:

  • Manage permissions of instance.
  • Change the owner of the root instance.
  • Change the documentation of instance (label and description).

Notes  :

  • An administrator or an owner of an adaptation can have a restricted access to an instance through permission definitions, but in any case, he will keep the possibility to perform tasks defined above. This implies that an administrator always sees all adaptation instances and that any user sees all adaptation instances that he owns.
  • An administrator or the owner of the technical adaptation named "mdm-repository" can modify in any case this one, whatever their restrictions on it.

Particular privileges on branches

A user is a "super owner" of a branch when:

  • He is an owner of the branch and he is allowed to manage its permissions;
  • or he is an owner of an ancestor branch and he is allowed to manage the permissions of this ancestor.

For a specific branch, the general rule is that only an administrator or a "super owner" may perform the following administration tasks:

  • Manage permissions of branch.
  • Change owner of branch.
  • Lock and unlock branch.
  • Change documentation of branch (label and description).

Notes  : An administrator or an owner of a branch can have a restricted access to it through permission definitions, but in any case, he will keep the possibility to perform administration tasks defined above. This implies that an administrator always sees all open branches and that any user sees all the branches that he owns.

Agreements and delegation

Agreements allow to delegate master data management to the built-in dynamic DISTRIBUTOR role.

We have the following specific behaviors:

  • On an agreement itself, if the user is a distributor, this user has at least a read only access at instance level.
  • Under an agreement, a user that is not a distributor has at most a read only access.
  • Under an agreement, permissions cannot be managed. However instances can still define permissions that were created before a parent instance has been set as an agreement.

Merge and permissions

When a branch is merged, the permissions of its parent branch are not impacted but the permissions of adaptation instances of the parent branch are merged if and only if the user specifies it during the merge process.

Definition of permissions with webMethods Master Data Manager

As described below, each level has similar schema that allows the definition of several associations (or rules) of type: "To a given profile, given permissions".

Permissions on branches

For a given branch, several associations "profile-permissions" can be specified. For each defined profile, allowed permissions are the following:

  1. Branch access: defines access rights (read-write, read only, hidden).
    2. Read-write
    • The user can see the branch.
    • The user has the right to access adaptations according to his rights on these last.
    Read only
    • The user can visualize the branch and its versions. He can see the child branches if he has the right of doing so.
    • The user can at most visualize the contents of the branch. He cannot modify the branch contents.
    Hidden
    • The user can see neither the branch nor its versions.
    • If the user has access to a child branch then he can see the current branch but cannot select it.
    • The user cannot access to the branch contents (adaptations contents).
    • The user cannot performs actions on the branch.

  2. Restriction: it indicates if a given permission in a "profile (role or user) - permission (droit ou action)" association, should have priority over the other permissions related to the same profile. Finally, the prior (considered) permission corresponds to the minimum permission over the "profile-permission(s)" associations that have been restricted.
  3. Create a branch: indicates if it is possible to create a child branch from the current branch.
  4. Create a version: indicates if it is possible to create a version of the current branch.
  5. Merge a branch: indicates if a profile has the right to merge a branch with its parent branch.
  6. Close a branch: indicates if a profile has the right to close the current branch.
If the current profile has the right to create a child branch, one can specify a "template" of permissions related to this child branch. This "template" defines the following information:
  • Create a branch
  • Create a version
  • Merge a branch
  • Close a branch
  • Change the owner
  • Change the permissions
When a user creates a child branch (if he is allowed to do so), these permissions are automatically assigned to the profile "owner" of the new child branch.

Note that only the administrator and the owner of a branch can define a new owner for this branch or modify the associated permissions. For that, they should modify general information on the branch ("owner role") and also permissions of the different users.

Permissions on instances

For a given adaptation instance above an agreement (included), several "profile-permissions" associations can be specified. For each defined profile, permissions are the following:

Actions on instance

  • Restricted mode: it indicates if a given permission in a "profile (role or user) - permission (right or action)" association, for the current instance, should have priority over the other permissions related to the same profile. Finally, the prior (considered) permission corresponds to the minimum permission over the "profile-permission(s)" associations that have been restricted.
  • Create a child adaptation: indicates if a given profile has the right to create a child adaptation.
  • Manage agreement: indicates if a given profile has the right to create an agreement from a given adaptation.
  • Duplicate adaptation: indicates if a given profile has the right to duplicate an adaptation.
  • Change the adaptation parent: indicates if a given profile has the right to change the parent adaptation of a given child adaptation.

Default actions on tables

For a given table, several "profile-permissions" associations can be specified. For each defined profile, possible actions are the following:

  • Create a record: indicates if a profile has the right to create records in a table.
  • Modify a record: indicates if a profile has the right to modify a record (in case of inheritance of data in an adaptation tree).
  • Hide a record: indicates if a profile has the right to hide a record in a table.
  • Duplicate a record: indicates if a profile has the right to duplicate a record in a table.
  • Delete a record: indicates if a profile has the right to delete a record in a table.

Permissions on tables

Actions specified on tables modify the default actions (cf. above) on these tables in the adaptation instance.

Default access right on nodes values

  • Read-write: nodes can be consulted and modified (modification of values).
  • Read: nodes can only be consulted, not modified.
  • Hidden: nodes are hidden.

Permissions on terminal nodes

Rights specified on terminal nodes modify the default rights (cf. above) on these terminal nodes.

Resolution of permissions

The resolution of permissions is always done in the context of a user session. In general, a restrictive resolution is performed between a given level and its parent level. Hence at a given level, a user cannot have a permission higher than the one resolved at a parent level.

We can also notice that programmatic permissions can be invoked as well. These programmatic access rights are always restrictive.

Solving access rights

General principles for a user

  • If a user is associated to different access rights at a given level and if restrictions have been defined for these "user-rights" associations, then the minimum of the restricted rights is applied. If there is no restrictions then the maximum access right is applied for the given user (cf. tables below).

    Users
    Access rights
    Restriction
    User 1
    read-write no
    read yes
    hidden yes
    User 2
    read-write no
    read yes
    hidden no
    User 3
    read-write no
    read no
    hidden no

    Users
    Right applied
    User 1 hidden
    User 2 read
    User 3 read-write

  • Rights defined on an adaptation will be applied on its child adaptations. It is possible to modify these rights on the child adaptations. The inheritance mecanism is thererfore apply for either values or access rights.
  • At a given level, the most restrictive right of this level and of the higher levels is applied. For instance, if an adaptation instance is in read-write access and the container branch allows only reading then the user will have a read only access right on this adaptation.

At the branch level, the access right will be the following: if a user has several rights defined (one for each of his roles) and if restrictions have been defined then the minimum of the restricted "user-rights" associations is applied. Otherwise, the maximum of the "user-rights" associations of the given user is applied. On the other hand, if the user has no right defined then the branch will be hidden to him.

At the instance level, the same principle than the one applied to branches is used. Moreover, access right on instance is defined by the minimum between the right on the branch and the right on the instance (identified by using the "solving rights" principle similar to the one applied at the branches level). For instance, if a branch is in read only access for the user U and an adaptation of the branch is in read-write access for the same user, then U will have a read only access on the adaptation.

At the node level, the same principle than the one applied to branches and to instances is used. Moreover, the right on the node is defined by the minimum between the right on the instance, the right on the node (identified by using the "solving rights" principle similar to the one applied at the branches level and at the instances level) and the programmatic access rights on nodes if defined.

Note that for hiding a branch (respectively an instance or a node) to all users, the administrator or the owner of this branch should define a restriction on the association between the built-in profile "Profile.EVERYONE" and the access right "hidden".

Solving actions

General principles for a user

When several actions lists are defined for a given profile on an adapatation instance (respectively table), the actions list to considered is dynamically generated after an evaluation of each action type among the different lists (of actions) associated to these user. If some "user-(list of) actions" associations are restricted, then for each action type we verify wether it is forbidden at least once to forbid it at all. If there is no restrictions then if at least one action type is authorized then the action is finally allowed (cf. tables below for actions on tables).

Actions lists
Users
 Create a record Modify a record Hide a record Duplicate a record Delete a record
Restriction
User 1
allowed forbidden allowed forbidden allowed no
allowed allowed forbidden allowed forbidden yes
allowed forbidden allowed allowed forbidden yes
User 2
allowed forbidden forbidden allowed forbidden no
allowed forbidden forbidden allowed forbidden no
allowed allowed forbidden forbidden forbidden no

Users
Actions list applied
User 1
Create a record
Duplicate a record
User 2
Create a record
Modify a record
Duplicate a record

 

Illustrations: defining permissions with webMethods Master Data Manager

a) Permission on a branch

On the branch page, select the link "access rights":

This link gives access to the following table:

This table presents permissions for the current branch. The link "New", 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 the child branch created by this profile. For example, the owner of a current branch gives permission to profile X for accessing the branch and creating a child branch. Actions allowed for profile X, on the branch he will create, are defined in section "B".

b) Permissions on adaptation instance

In an instance, tab "Access rights" allows to access 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 link "New". This page also allows existing permissions modification if one has this right :

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 allows to define specific permissions policy for tables or nodes by clicking on the corresponding link "Add an occurrence".

c) Specific rights on nodes

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

Access rights on nodes are defined by clicking on the corresponding link named "Add an occurrence". One can define an access right for each node of the adaptation instance ( see figure below):

d) Specific rights on services

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

By default all services are enabled. The button Disable disables the selected service. To enable a service, this one has to be selected in the list of disabled services and activated with the button Enable.

Permissions

Les permissions spécifient et régulent l'accès de chaque utilisateur aux données de référence et les actions qu'il peut effectuer.

Principes généraux

Spécification des permissions

Les permissions portent sur des actions (action autorisée ou action non autorisée) et des droits d'accès (non visible, lecture et lecture/écriture). Les principales entités contrôlées par les permissions sont :

  1. les branches,
  2. les instances,
  3. les tables,
  4. les noeuds terminaux.

Les permissions peuvent être spécifiées de deux manières :

Résolution des permissions

Les permissions sont toujours résolues dans le contexte d'une session utilisateur authentifiée. Les règles définies pourront ainsi prendre en compte les informations associées à cet utilisateur, en particulier les rôles qui lui sont attribués.

Le processus de résolution est détaillé dans le chapitre Résolution des permissions.

Remarque: A partir d'un environnement Java, la classe SessionPermissions fournit l'accès aux permissions résolues.

Utilisateurs, Rôles et Profils

La définition et la résolution des permissions utilisent largement la notion de profil, terme générique qui permet de désigner soit un identifiant utilisateur soit un rôle.

Chaque utilisateur peut avoir plusieurs rôles et chaque rôle peut être partagé par plusieurs utilisateurs. Ces informations sont définies dans l'annuaire webMethods MDM.

Définitions particulières :

  • Un utilisateur est un administrateur s'il participe au rôle prédéfini ADMINISTRATOR.
  • Un utilisateur est un propriétaire d'une instance s'il participe au profil défini pour l'attribut "propriétaire" de l'instance racine. En ce cas, le rôle prédéfini OWNER sera activé dans le contexte d'une résolution de permission sur l'instance.
  • De même un utilisateur est un propriétaire d'une branche s'il participe au profil défini pour l'attribut "propriétaire" de la branche. En ce cas, le rôle prédéfini OWNER sera activé dans le contexte d'une résolution de permission sur la branche.
  • Un utilisateur est un distributeur d'un accord (ou d'une instance sous l'accord), s'il participe au profil défini pour l'attribut "distributeur" de l'accord. En ce cas, le rôle prédéfini DISTRIBUTOR sera activé dans le contexte d'une résolution de permission sur l'instance.

Privilèges particuliers sur les instances

Pour une instance spécifique, les tâches ci-dessous sont accessibles uniquement si l'utilisateur est un administrateur ou un propriétaire de cette instance :

  • Gérer les permissions de cette instance.
  • Modifier l'attribut "propriétaire" de l'instance racine.
  • Modifier la documentation de cette instance (libellé et description).

Notes :

  • Un administrateur ou un propriétaire d'une instance peuvent avoir un accès restreint à celle-ci au travers des permissions définies, mais dans tous les cas, un tel utilisateur conservera la possibilité d'exécuter les tâches décrites ci-dessus. Cela implique qu'un administrateur voit toujours toutes les instances et que tout utilisateur voit toutes les instances qu'il possède.
  • Un administrateur ou le propriétaire de l'adaptation technique nommée "mdm-repository" pourront dans tous les cas modifier cette adaptation, quelles que soient leurs restrictions sur celle-ci.

Privilèges particuliers sur les branches

Nous disons qu'un utilisateur est un "super propriétaire" d'une branche si :

  • il est un propriétaire de cette branche et il est autorisé à gérer ses permissions;
  • ou il est un propriétaire d'une branche ancêtre et il est autorisé à gérer les permissions de cette branche ancêtre.

Pour une branche spécifique, les tâches ci-dessous sont accessibles uniquement si l'utilisateur est un administrateur ou un "super propriétaire" de cette branche :

  • Gérer les permissions de la branche.
  • Modifier l'attribut "propriétaire" de la branche.
  • Modifier la documentation de la branche (libellé et description).

Notes : Un administrateur ou un "super propriétaire" d'une branche peuvent avoir un accès restreint à celle-ci au travers des permissions définies, mais dans tous les cas, un tel utilisateur conservera la possibilité d'exécuter les tâches décrites ci-dessus. Cela implique qu'un administrateur voit toujours toutes les branches ouvertes et que tout utilisateur voit toutes les branches dont il est le "super propriétaire".

Accords et délégation

Les accords permettent de déléguer la gestion des données de référence au rôle prédéfini DISTRIBUTOR.

Nous avons les comportements spécifiques suivants :

  • Sur un accord, si l'utilisateur est un distributeur, cet utilisateur a au minimum un accès en lecture seule au niveau instance.
  • Sous un accord, si l'utilisateur n'est pas un distributeur, il aura au maximum un accès en lecture seule.
  • Sous un accord, aucune permission ne peut être gérée. Cependant les instances peuvent conserver des permissions définies antérieurement.

Fusion et permissions

Quand une branche est fusionnée, les permissions de niveau branche de la branche parente ne sont pas impactées mais les permissions de niveau instance et inférieures sont fusionnées si l'utilisateur le demande explicitement lors du processus de fusion.

Définition des permissions avec webMethods Master Data Manager

Ainsi que détaillé ci-dessous, chaque niveau a un schéma similaire qui permet de définir plusieurs associations (ou règles) de type : "A tel profil sont associées les permissions suivantes".

Permissions sur les branches

Pour une branche donnée, plusieurs associations "profil-permissions" peuvent être spécifiées. Pour chaque profil défini, les permissions possibles sont les suivantes :

  1. Accès à la branche : permet de préciser les droits d'accès (lecture-écriture, lecture seule, non visible).

    2. Lecture-écriture
    • L'utilisateur peut voir la branche.
    • L'utilisateur a le droit d'accéder aux adaptations, en respectant ses droits d'accès sur ces dernières.
    Lecture seule
    • L'utilisateur peut voir la branche et ses versions. Il peut voir les branches filles si les droits sur celles-ci le lui permettent.
    • L'utilisateur peut au plus voir le contenu de la branche. Il ne peut pas modifier le contenu de la branche.
    Non visible
    • L'utilisateur ne peut pas voir la branche ni ses versions.
    • Si l'utilisateur a accès à une sous branche alors il peut voir la branche courante mais ne peut pas la sélectionner.
    • L'utilisateur ne peut pas accéder au contenu de la branche (à ses adaptations).
    • L'utilisateur ne peut pas effectuer d'actions sur la branche.

  2. Restriction : elle indique si une permission dans une association "profil (rôle ou utilisateur) - permission (droit ou action)", pour la branche courante, doit être prise en compte de façon prioritaire par rapport aux autres permissions associées au même profil. La permission appliquée (prioritaire) correspond, en définitive, au minimum des permissions sur les associations "profil-permission(s)" qui ont été restreintes.
  3. Créer une branche : indique s'il est possible de créer une sous-branche dans la branche courante.
  4. Créer une version : indique s'il est possible de créer une version de la branche courante.
  5. Fusionner la branche : indique si un profil a le droit de fusionner la branche avec la branche parente.
  6. Fermer la branche : indique si un profil a le droit de fermer la branche courante.
Si le profil courant est autorisé à créer une branche fille, on peut de plus préciser un "template" de permissions sur la branche fille. Ce "template" définit les informations suivantes :
  • Créer une branche
  • Créer une version
  • Fusionner la branche
  • Fermer la branche
  • Changer de propriétaire
  • Changer les permissions
Lorsque l'utilisateur crée une branche fille (s'il en a l'autorisation), ces permissions sont automatiquement attribuées au profil "propriétaire" pour la nouvelle branche fille.

Notons que seul l'administrateur et le propriétaire d'une branche peuvent définir un nouveau propriétaire de cette branche ou en modifier les permissions associées. Pour cela, ils doivent modifier les informations générales sur la branche (rôle propriétaire entre autres) ainsi que les permissions des différents utilisateurs.

Permissions sur les instances

Pour une instance d'adaptation donnée située au dessus d'un accord (inclus), plusieurs associations "profil-permissions" peuvent être spécifiées. Pour chaque profil défini, les permissions possibles sont les suivantes :

Actions sur l'instance

  • Mode restreint : il indique si une permission dans une association "profil (rôle ou utilisateur) - permission (droit, action)", pour l'instance courante, doit être prise en compte de façon prioritaire par rapport aux autres permissions associées au même profil. La permission appliquée (prioritaire) correspond, en définitive, au minimum des permissions sur les associations "profil-permission(s)" qui ont été restreintes.
  • Créer une adaptation fille : indique si le profil donné a le droit de créer une adaptation fille.
  • Gérer des accords : indique si le profil donné est autorisé à créer un accord à partir de cette adaptation.
  • Dupliquer l'adaptation : indique si le profil donné est autorisé à dupliquer l'adaptation.
  • Changer le parent de l'adaptation : indique si le profil donné est autorisé à changer l'adaptation parente d'une adaptation fille.

Actions par défaut sur les tables

Pour une table donnée, plusieurs associations "profil-permissions" peuvent être spécifiées. Pour chaque profil défini, les actions possibles sont les suivantes :

  • Créer un enregistrement : indique si le profil est autorisé à créer une occurrence dans la table.
  • Surcharger un enregistrement : indique si le profil est autorisé à surcharger un enregistrement (dans le cas de l'héritage de données dans un arbre d'adaptation).
  • Occulter un enregistrement : indique si le profil est autorisé à cacher un enregistrement de la table.
  • Dériver un enregistrement : indique si le profil est autorisé à dupliquer un enregistrement de la table.
  • Supprimer un enregistrement : indique si le profil est autorisé supprimer un enregistrement de la table.

Permissions sur les tables

Les actions spécifiées sur les tables surchargent les actions par défaut (voir ci-dessus) sur ces tables dans l'instance.

Droit d'accès par défaut sur les valeurs des noeuds

  • Lecture-Ecriture : les noeuds peuvent être consultés et modifiés (mise à jour des valeurs).
  • Lecture : les noeuds peuvent uniquement être consultés mais pas modifiés.
  • Non visible : les noeuds sont non visibles.

Permissions sur les noeuds terminaux

Les droits définis sur les noeuds terminaux surchargent le droit par défaut (voir ci-dessus) sur les valeurs des noeuds de l'instance.

Résolution des permissions

La résolution des permissions est toujours effectuée dans le contexte d'une session utilisateur. De manière générale, il est important de comprendre qu'une résolution restrictive est effectuée entre un niveau et ses niveaux supérieurs. Concrètement, l'utilisateur ne peut pas avoir une permission plus élevée que celle résolue à un niveau supérieur.

Notons également que des permissions programmatiques seront également invoquées si elles sont spécifiées. Le résultat de ces règles programmatiques sera alors systématiquement pris en compte de manière restrictive.

Résolution des droits

Principes généraux pour un utilisateur

  • Si un utilisateur est associé à différents droits d'accès à un niveau donné et si des restrictions ont été définies pour ses associations "utilisateur-droits", alors le minimum des droits est appliqué. S'il n'y a pas de restrictions définies, alors c'est le maximum des droits qui est appliqué pour utilisateur considéré (cf. tableaux ci-dessous).

    utilisateurs
    Droits d'accès
    Restriction
    utilisateur 1
    lecture-écriture non
    lecture oui
    non visible oui
    utilisateur 2
    lecture-écriture non
    lecture oui
    non visible non
    utilisateur 3
    lecture-écriture non
    lecture non
    non visible non

    utilisateurs
    Droit appliqué
    utilisateur 1 non visible
    utilisateur 2 lecture
    utilisateur 3 lecture-écriture

  • Les droits définis sur une adaptation seront appliqués sur ses adaptations filles. Il est possible de surcharger ces droits dans une adaptation fille. Le mécanisme d'héritage est ainsi mis en oeuvre non seulement pour les valeurs mais aussi pour les droits.
  • A un niveau donné, le droit le plus restrictif de ce niveau et des niveaux supérieurs est adopté. Par exemple, si une adaptation instance est en lecture-écriture mais que la branche contenante ne permet que la lecture alors l'utilisateur a un droit en lecture seule sur l'adaptation.

Au niveau de la branche, le droit d'accès considéré sera le suivant : si un utilisateur a plusieurs droits définis (un pour chacun de ses rôles, par exemple) et si des restrictions ont été définies alors le minimum des associations "utilisateur-droits" restreintes est appliqué. Sinon, c'est le maximum des associations "utilisateur-droits" de l'utilisateur considéré qui est appliqué. Par ailleurs, si l'utilisateur n'a aucun droit défini alors par défaut cette branche lui sera cachée.

Au niveau de l'instance, le même principe que celui appliqué aux branches est utilisé. De plus, le droit d'accès sur l'instance est défini par le minimum entre le droit sur la branche et le droit sur l'instance (identifié en utilisant un principe de résolution des droits identique à celui appliqué au niveau des branches). Par exemple, si la branche est en lecture seule pour l'utilisateur U et une adaptation de la branche est en écriture pour ce même utilisateur, alors U n'aura qu'un accès en lecture sur l'adaptation.

Au niveau du noeud, le même principe que celui appliqué aux branches et aux instances est utilisé. De plus, le droit sur le noeud est défini par le minimum entre le droit sur l'instance, le droit sur le noeud (identifié en utilisant un principe de résolution des droits identique à celui appliqué au niveau des branches et des instances) et les droits d'accès programmatiques sur le noeud s'ils sont définis.

Notons que pour cacher une branche (respectivement une instance ou un noeud) à tous les utilisateurs, il suffirait à l'administrateur ou au propriétaire de cette branche de définir une restriction sur l'association entre le profil prédéfini "Profile.EVERYONE" et le droit d'accès "non visible".

Résolution des actions

Principes généraux pour un utilisateur

Lorsque plusieurs listes d'actions sont définies pour un utilisateur donné sur une instance d'adaptation (respectivement table), la liste d'actions à considérer est générée dynamiquement après évaluation de chaque type d'action dans les différentes listes (d'actions) associées à cet utilisateur. Si l'association "utilisateur-(liste) actions" est restreinte, alors pour chaque action on vérifie si elle est non autorisée au moins une fois pour l'interdir. S'il n'y a pas de restriction, il suffit qu'une action soit autorisée au moins une fois pour être validée (cf. tableaux ci-dessous pour des actions sur des tables).

Liste d'actions
Utilisateurs
 Créer un enregistrement Surcharger un enregistrement Occulter un enregistrement Dériver un enregistrement Supprimer un enregistrement
Restriction
Utilisateur 1
autorisé interdit autorisé interdit autorisé non
autorisé autorisé interdit autorisé interdit oui
autorisé interdit autorisé autorisé interdit oui
Utilisateur 2
autorisé interdit interdit autorisé interdit non
autorisé interdit interdit autorisé interdit non
autorisé autorisé interdit interdit interdit non

Utilisateurs
Liste d'actions appliquées
Utilisateur 1
Créer un enregistrement
Dériver un enregistrement
Utilisateur 2
Créer un enregistrement
Surcharger un enregistrement
Dériver un enregistrement

Illustrations : définition de permissions avec webMethods Master Data Manager

a) Permissions sur une branche

Sur la page principale de la branche, sélectionnez le lien "droits d'accès" :

Ce lien permet d'accéder à la page suivante :

Cette page présente les permissions pour la branche en cours. Le lien "Créer", dans cette page, permet d'ajouter une permission pour un profil donné sur une page similaire à celle présentée ci-dessous :

La première section, "A" dans la figure ci-dessus, permet de définir un droit d'accès sur la branche courante ainsi que les actions possibles. La seconde section, "B" dans la figure ci-dessus, permet de définir les actions qui seront autorisées sur la sous branche qui sera créée par ce profil. Par exemple, le propriétaire de la branche courante autorise le profil X à accéder à la branche et à créer une sous branche. Les actions autorisées pour le profil X, sur la branche qu'il créera, sont définies en "B".

b) Permissions sur une instance d'adaptation

Dans une adaptation, l'onglet "droits d'accès" permet d'accéder à la page des permissions de l'instance :

Une première page d'édition des permissions sur l'instance apparaît avec le lien "Droits d'accès par profil" pour l'édition des permissions pour un profil donné (cf. figure ci-dessous) :

Ensuite, une seconde page qui présente les permissions pour l'instance permet la création de permissions. Pour cela, il faut cliquer sur le lien "créer". Cette page permet également la modification de permissions existantes si on en a le pouvoir :

La page d'édition des permissions sur l'instance est présentée ci-dessous :

La page précédente permet d'éditer les actions autorisées sur l'instance (création d'une adaptation fille, gestion des accords, etc.). Elle permet aussi de définir les actions par défaut sur les tables et les droits d'accès par défaut sur les noeuds de l'instance d'adaptation.

Cette page va permettre également de définir des permissions spécifiques pour des tables ou pour des noeuds quelconques en cliquant sur les liens "Ajouter une occurrence" correspondants.

c) Droits spécifiques sur des noeuds

Pour les noeuds table, différentes actions peuvent être définies (créer un enregistrement, occulter un enregistrement, etc.). Après avoir cliqué sur le lien correspondant "Ajouter une occurrence", on obtient une liste d'actions similaires à celle présentée ci-après :

Les droits d'accès sur les noeuds sont définis en cliquant sur le lien correspondant "Ajouter une occurrence". Il est possible de définir un droit d'accès pour chaque noeud de l'adaptation (cf. figure ci-après) :

d) Droits spécifiques sur les services

Les droits d'accès sur les services permettent d'activer ou de désactiver un service (cf. figure ci-après) :

Par défaut les services associés à l'adaptation sont tous activés. La liste déroulante permet de sélectionner un service à désactiver. Le bouton Désactiver permet de désactiver le service sélectionné. Pour réactiver un service, il faut le sélectionné dans la liste des services désactivés puis cliquer sur le bouton Activer.

 

Home > Engine & Repository