Permissions

Dernière publication : Aug 10, 2026
Les permissions définissent l'accès aux données et les actions disponibles pour chaque utilisateur.
Related information

Présentation

Les permissions permettent de définir si une action est autorisée. Elles définissent aussi les droits d'accès d'une entité : cachée, en lecture, ou en lecture-écriture. Les entités principales contrôlées par les permissions sont les suivantes :
  • Espace de données
  • Jeu de données
  • Table
  • Groupe
  • Champ

Utilisateurs, fonctions et profils

La définition et la résolution des permissions sont basées sur la notion de profils, terme générique faisant référence aux utilisateurs ou aux rôles.
Chaque utilisateur peut avoir plusieurs rôles, et un même rôle peut être partagé par plusieurs utilisateurs.
Ces relations sont définies dans le référentiel des rôles et utilisateurs. Voir Users and roles directory.
Définitions particulières:
  • Un administrateur est un membre du rôle built-in 'ADMINISTRATEUR'.
  • Un propriétaire d'un jeu de données est un membre de l'attribut propriétaire spécifié dans les informations d'un jeu de données racine. Dans ce cas, le rôle built-in 'PROPRIÉTAIRE' est activé lorsque les permissions sont résolues dans le contexte du jeu de données.
  • Un propriétaire d'un espace de données est un membre de l'attribut propriétaire spécifié pour un espace de données. Dans ce cas, le rôle built-in 'PROPRIÉTAIRE' est activé lorsque les permissions sont résolues dans le contexte de l'espace de données.

Règles de permission

Une règle de permission définit les autorisations accordées à un profil pour une entité donnée.
Les règles de permission définies par l'utilisateur sont créées via l'interface utilisateur. Voir la section Définition des règles utilisateur.
Les règles de permission programmatiques peuvent être créées par des développeurs. Voir la section Définition des règles programmatiques.

Résolution des permissions

Les permissions sont toujours résolues dans le contexte d'une session utilisateur authentifiée. Ainsi, les permissions sont principalement basées sur les profils de l'utilisateur.
En général, la résolution est restrictive entre un niveau donné et son niveau parent. Ainsi, pour n'importe quel niveau donné, un utilisateur ne peut pas avoir de permission supérieure à celle résolue au niveau d'un de ses parents.
Les permissions programmatiques sont toujours considérées comme étant restrictives.
Note:
Dans l'API Java, la classe SessionPermissions permet d'accéder aux permissions résolues.
Voir aussi:

Permissions spéciales du propriétaire et de l'administrateur

Sur un jeu de données

Un administrateur ou un propriétaire de jeu de données peut effectuer les actions suivantes sur le jeu de données :
  • Gérer ses permissions
  • Changer son propriétaire, s'il est un jeu de données racine
  • Modifier ses informations générales (libellés et descriptions localisés)
Attention:
Bien que la définition des permissions puisse restreindre les droits d'affichage ou d'exécution de certaines actions pour l'administrateur ou le propriétaire du jeu de données, il reste possible pour ces derniers de modifier leur propre accès, puisqu'ils auront toujours accès à la gestion des permissions.

Sur un espace de données

Pour devenir le super propriétaire d'un espace de données, un utilisateur doit :
  • Être propriétaire de l'espace de données et être autorisé à gérer ses permissions, ou
  • Être propriétaire d'un espace de données qui est l'ancêtre de l'espace de données courant et être autorisé à gérer les permissions de cet espace de données ancêtre.
    L'administrateur ou le super propriétaire d'un espace de données peut réaliser les actions suivantes sur l'espace de données :
  • Gérer ses permissions
  • Changer son propriétaire
  • Le verrouiller ou le déverrouiller
  • Modifier ses informations générales (libellés et descriptions localisés)
De plus, dans un workflow, lors de l'utilisation des scripts task intégrés 'Créer un espace de données' ou 'Créer une image', les permissions résolues sont calculées en utilisant le propriétaire défini dans la configuration du script task plutôt que dans la session courante. Cela s'explique par le fait que, pour ces cas, la session courante est associée à un utilisateur système.
Attention:
Bien que la définition des permissions puisse restreindre les droits d'affichage ou d'exécution de certaines actions pour l'administrateur ou le propriétaire de l'espace de données, il reste possible pour ces derniers de modifier leur propre accès, puisqu'ils auront toujours accès à la gestion des permissions.

Impact de la fusion sur les permissions

Lorsqu'un espace de données est fusionné, les permissions du jeu de données de l'espace de données enfant sont fusionnées avec celles du jeu de données de l'espace de données parent si et seulement si l'utilisateur le précise pendant le processus de fusion. Les permissions de l'espace de données parent ne sont jamais impactées.
Si certains éléments sont masqués pour le profil qui tente de réaliser une fusion, l'action ne sera pas réalisable, car l'impact de la fusion sur les données ne sera pas entièrement visible.

Aspects importants concernant les permissions

Il faut garder à l'esprit les recommandations suivantes lorsqu'on travaille avec les permissions :
  • Lorsqu'une permission hidden est retournée sur un champ pour une session donnée, un utilisateur pourrait "deviner" des informations normalement interdites en filtrant ou en triant sur ce champ dans les cas suivants :
    • En utilisant une Request sur cette table avec les permissions activées. Pour éviter cela, les permissions sur ce noeud doivent être vérifiées explicitement avant d'appliquer le filtre ou le critère de tri.
    • En définissant une vue personnalisée sur cette table dans l'IHM. Pour éviter cela, la permission de définir des vues personnalisées devrait être restreinte pour ces utilisateurs.
  • La résolution des libellés personnalisés de tables (propriété 'defaultlabel') et de relations (propriété 'display') ne tient pas compte des permissions. Les champs habituellement masqués du fait des restrictions de droits d'accès, seront affichés dans ces libellés. Aucun de ces libellés ne devrait donc contenir de champ confidentiel. Sinon, une stratégie de permission doit être définie afin de restreindre l'affichage de l'intégralité du libellé.
  • Lorsqu'une procédure désactive toutes les vérifications de permission en utilisant ProcedureContext.setAllPrivileges, le code client doit vérifier que la session de l'utilisateur courant est autorisée à exécuter la procédure.
  • Lors de l'exécution d'une action sur table (création, suppression, surcharge, occultation) dans une procédure, le droit d'accès du noeud de la table pour la session utilisateur est ignoré durant la résolution des permissions. Lorsque ce contrôle doit être effectué, le code client doit au préalable appeler explicitement SessionPermissions.getNodeAccessPermission dans la procédure.
  • Afin d'optimiser la résolution des permissions, un cache dédié est mis en place au niveau de la session ; il ne prend en compte que les règles définies par l'utilisateur, et non les règles programmatiques (celles-ci ne sont pas mises en cache car elles sont contextuelles et dynamiques). Le cycle de vie du cache de session dépend du contexte, voir l'explication ci-dessous :
    • Dans l'IU, le cache est vidé pour chaque événement non-ajax (i.e affichage de page, ouverte de pop-up, etc.).
    • Dans les procédures programmatiques, le cache n'est vidé qu'à la fin de la procédure, à moins d'être explicitement vidé (voir ci-dessous).
      Attention:
      Lors de la modification de permissions dans un contexte de procédure (import d'une archive EBX® ou fusion programmatique d'un espace de données), le cache de la session doit être vidé via un appel à Session.clearCache. Autrement, ces modifications ne seront pas prises en compte avant la fin de la procédure.

Définition des règles utilisateur

Tous les niveaux utilisent un schéma similaire, qui permet la définition de règles de permission pour les profils.

Définition des règles utilisateur dans les espaces de données

Pour un espace de données, les permissions administrables pour chaque profil sont les suivantes :
Mode
Autorisation
Écriture
  • Peut voir l'espace de données.
  • Peut accéder aux jeux de données en fonction des permissions du jeu de données.
Lecture seulement
  • Peut voir l'espace de données et ses images.
  • Peut voir les espaces de données enfants, si autorisé par les permissions.
  • Peut voir le contenu de l'espace de données, sans pouvoir le modifier.
Masqué
  • Ne peut voir ni l'espace de données ni ses images.
  • Si autorisé à voir l'espace de données enfant, peut voir l'espace de données courant sans pouvoir le sélectionner.
  • Ne peut accéder au contenu de l'espace de données, ni aux jeux de données.
  • Ne peut réaliser aucune action sur l'espace de données.
Restriction d'accès
Indique si cette association profil-permission de l'espace de données doit être prioritaire sur les autres règles de permissions.
Créer un espace de données enfant
Indique si le profil peut créer des espaces de données enfants à partir de l'espace de données courant.
Créer une image enfant
Indique si le profil peut créer une image de l'espace de données courant.
Initialiser la fusion
Indique si le profil peut fusionner l'espace de données courant avec son espace de données parent.
Exporter une archive
Indique si le profil peut exporter l'espace de données courant comme archive.
Importer une archive
Indique si le profil peut importer une archive dans l'espace de données courant.
Fermer un espace de données
Indique si le profil peut fermer l'espace de données courant.
Fermer une image
Indique si le profil peut fermer une image de l'espace de données courant.
Droits sur les services
Indique si un profil a le droit d'exécuter des services sur l'espace de données. Par défaut, tous les services d'espaces de données sont autorisés. Un administrateur ou super propriétaire de l'espace de données courant ou un utilisateur donné autorisé à modifier les permissions sur l'espace de données courant peut modifier ces permissions afin de restreindre les services de l'espace de données pour certains profils.
Permissions de l'espace de données enfant à la création
Lorsqu'un utilisateur crée un espace de données enfant, les permissions de ce nouvel espace de données sont automatiquement attribuées au propriétaire du profil, conformément aux permissions définies sous 'Permissions d'un espace de données enfant à la création' dans l'espace de données parent. Si plusieurs permissions sont définies pour le propriétaire via différents rôles, le profil du propriétaire se comporte de la même manière qu'un autre profil et les permissions sont résolues de la même manière.

Définition des règles utilisateur dans les jeux de données

Pour un jeu de données, les permissions administrables pour chaque profil sont les suivantes :

Actions sur les jeux de données

Restriction d'accès
Indique si l'association profil-permission du jeu de données doit être prioritaire sur les autres règles de permissions.
Créer un jeu de données enfant
Indique si le profil a le droit de créer un jeu de données enfant à partir du jeu de données courant.
Dupliquer un jeu de données
Indique si le profil a le droit de dupliquer le jeu de données courant.
Modifier le jeu de données parent
Indique si le profil a le droit de changer le jeu de données parent d'un jeu de données enfant.

Actions sur les tables

Les droits d'actions sur les tables par défaut sont définis au niveau du jeu de données. Il est ensuite possible de surcharger ces droits par défaut pour une ou plusieurs tables données. Les permissions administrables pour chaque profil sont les suivantes :
Créer un enregistrement
Indique si le profil a le droit de créer des enregistrements dans la table.
Surcharger un enregistrement
Indique si le profil a le droit de surcharger les enregistrements de la table.
Occulter un enregistrement
Indique si le profil a le droit d'occulter les enregistrements de la table.
Supprimer un enregistrement
Indique si le profil a le droit de supprimer des enregistrements dans la table.

Droits d'accès sur les valeurs de noeud

Les permissions définies sur des noeuds terminaux spécifiques surchargent les droits d'accès par défaut.
Lecture-écriture
Peut afficher et modifier les valeurs du noeud.
Lecture
Peut afficher les noeuds, mais ne peut pas modifier leurs valeurs.
Masqué
Ne peut pas voir les noeuds.

Permissions sur les services

Un administrateur ou propriétaire de l'espace de données courant peut modifier les permissions par défaut d'un service afin de permettre ou limiter son usage pour certains profils.
Activé
Rend le service disponible pour le profil.
Désactivé
Rend le service indisponible pour le profil. Il ne sera ni affiché dans les menus, ni exécutable depuis un composant web.
Par défaut
Rend le service activé ou désactivé selon la permission par défaut définie lors de sa déclaration.
Voir ActivationContext.setDefaultPermission pour plus d'informations.

Définition des règles programmatiques

Les règles programmatiques permettent de définir plus précisément les conditions d'accès à une donnée ou à un service utilisateur en fonction du contexte.
Il existe plusieurs types de règles programmatiques :

Définition des règles d'accès aux données

Les AccessRules sont des règles permettant de définir programmatiquement et en fonction du contexte les droits de lecture/écriture sur un noeud du modèle de données ou sur les enregistrements d'une table.
La définition d'une AccessRule s'effectue ainsi :
  1. Création d'une règle sous la forme d'une classe Java implémentant l'interface AccessRule ou AccessRuleForCreate.
  2. Assignation de cette règle aux noeuds concernés dans l'extension du schéma : SchemaExtensions.
    Selon la cible (noeud(s) du modèle ou enregistrements) ou le type ( AccessRule oi AccessRuleForCreate) de la règle, plusieurs méthodes comme SchemaExtensionsContext.setAccessRuleForCreateOnNode ou SchemaExtensionsContext.setAccessRuleOnOccurrence sont disponibles.
    La règle ainsi assignée est dite "locale" et n'est exécutée que lorsque l'entité cible est sollicitée. Voir Résolution des permissions sur données pour plus d'informations.
    Attention:
    Une seule AccessRule peut être définie pour chaque noeud, espace de données ou enregistrement. Une seule AccessRuleForCreate peut être définie pour chaque noeud d'une table. Ainsi, la définition d'une nouvelle règle programmatique d'un certain type remplacera l'existante.

Définition des règles d'activation sur service

Les ServiceActivationRules sont des règles permettant de définir si un service est activé ou non pour un espace de données ou un jeu de données. Un service désactivé par ce moyen n'est jamais disponible dans l'entité pour laquelle il est désactivé, quel que soit le profil courant et ce pour l'exécution ou l'affichage, même dans les écrans de permissions.
La définition d'une ServiceActivationRule s'effectue ainsi :
  1. Création d'une règle sous la forme d'une classe Java implémentant l'interface ServiceActivationRuleForDataspace ou ServiceActivationRuleForDataset, selon le type de service.
  2. Assignation de cette règle aux services concernés au niveau de leur déclaration, selon le type de service via les méthodes ActivationContextOnDataspace.setActivationRule ou ActivationContextWithDatasetSet.setActivationRule.
    La règle ainsi assignée sera évaluée lors de l'évaluation de l'activation du service. Voir Résolution de permissions pour les services pour plus d'informations.

Définition des règles de permission sur service

Les ServicePermissionRules sont des règles avancées permettant de définir dynamiquement les conditions d'affichage et d'exécution d'un service en fonction du contexte (session courante, entité sélectionnée, etc.). Le service doit au préalable être activé pour le contexte courant pour que ce type de règle se déclenche.
La définition d'une ServicePermissionRule s'effectue de la façon suivante :
  1. Création d'une règle sous la forme d'une classe Java implémentant l'interface ServicePermissionRule.
  2. Assignation de cette règle aux services concernés :

Résolution des permissions sur données

Résolution des règles utilisateur

Les droits d'accès définis via l'interface utilisateur sont résolus sur quatre niveaux : espace de données, jeu de données, enregistrement (le cas échéant) et noeud.
Si un profil est associé à des droits d'accès restrictifs à un niveau donné, le minimum de tous les droits restrictifs définis à ce niveau est résolu. Si aucune restriction n'est définie pour ce niveau, le maximum de tous les droits d'accès définis pour ce niveau est résolu.
Lorsqu'une permission restrictive est définie pour un profil, elle devient prioritaire sur les autres permissions potentiellement accordées par les autres rôles de l'utilisateur. D'une manière générale, pour toutes les règles de permission définies par l'utilisateur qui s'appliquent à la session utilisateur courante :
  • Si certaines règles avec restrictions sont définies, les permissions minimales de ces règles restreintes sont appliquées.
  • Si aucune règle avec restrictions n'est définie, les permissions maximales de toutes les règles correspondantes sont appliquées.
Exemples :
Étant donné deux profils P1 et P2 concernant le même utilisateur, le tableau suivant présente les possibilités de résolution de permission de cet utilisateur à un service.
Autorisation de P1 Autorisation de P2 Résolution de permission du service
Activé Activé Activé. Les restrictions ne changent rien.
Désactivé Désactivé Désactivé. Les restrictions ne changent rien.
Activé Désactivé Activé, à moins que l'autorisation de P2 ne soit une restriction.
Désactivé Activé Activé, à moins que l'autorisation de P1 ne soit une restriction.
Cette politique de restriction est identique pour les droits d'accès aux données.
Dans un autre exemple, un espace de données peut être masqué pour tous les utilisateur en définissant une association restrictive entre le profil intégré "Profile.EVERYONE" et le droit d'accès "masqué".
Quel que soit le niveau, les droits d'accès les plus restrictifs entre ceux résolus à ce niveau et ceux résolus à un niveau plus élevé sont appliqués. Par exemple, si les permissions d'accès au jeu de données d'un utilisateur sont résolues en accès lecture-écriture, mais que l'espace de données qui le contient n'autorise que l'accès en lecture, l'utilisateur ne bénéficiera que de l'accès en lecture seule pour ce jeu de données.
Note:
Le mécanisme d'héritage de jeu données s'applique aux valeurs et aux droits d'accès. Plus précisément, les droits d'accès définis sur un jeu de données seront appliqués sur ses jeux de données enfants. Il est possible de surcharger ces droits dans le jeu de données enfant.

Exemple de résolution des droits d'accès

Dans cet exemple, trois utilisateurs appartiennent aux rôles définis et profils suivants :
Utilisateur
Profil
Utilisateur 1
  • utilisateur1
  • rôle A
  • rôle B
Utilisateur 2
  • utilisateur2
  • rôle A
  • rôle B
  • rôle C
Utilisateur 3
  • utilisateur3
  • rôle A
  • rôle C
Les droits d'accès des profils pour un élément donné sont les suivants :
Profil Droits d'accès Politique de restriction
utilisateur1 Masqué Oui
utilisateur3 Lecture Non
Rôle A Lecture/Écriture Non
Rôle B Lecture Oui
Rôle C Masqué Non
Après la résolution basée sur les droits d'accès du rôle et du profil ci-dessus, les droits appliqués à chaque utilisateur sont les suivants :
Utilisateur
Droits d'accès résolus
Utilisateur 1
Masqué
Utilisateur 2
Lecture
Utilisateur 3
Lecture/Écriture

Résolution des droits d'accès aux espaces de données et aux images

Au niveau de l'espace de données, les droits d'accès sont résolus de la manière suivante :
  • Si un utilisateur a plusieurs droits définis via plusieurs profils :
    • Si les droits incluent des restrictions, le minimum des associations restrictives profil-droits est appliqué.
    • Autrement, le maximum des associations profil-droits est appliqué.
  • Si l'utilisateur n'a pas de droits définis :
    • Si l'utilisateur est un administrateur ou le propriétaire de l'espace de données, l'accès en lecture-écriture est accordé pour cet espace de données.
    • Autrement, l'espace de données sera masqué.

Résolution des droits d'accès aux jeux de données

Au niveau du jeu de données, le même principe qu'au niveau de l'espace de données s'applique. Après la résolution des droits d'accès au niveau du jeu de données seul, les droits d'accès définitifs sont déterminés en prenant les droits les plus bas entre les droits résolus de l'espace de données et les droits résolus du jeu de données. Par exemple, si un espace de données est résolu en lecture seulement pour un utilisateur et qu'un de ses jeux de données est résolu en lecture-écriture, l'utilisateur ne bénéficiera que de l'accès en lecture seule pour ce jeu de données.

Résolution des droits d'accès aux noeuds

Au niveau du noeud, le même principe qu'aux niveaux de l'espace de données et du jeu de données s'applique. Après la résolution des droits d'accès au niveau du noeud seul, les droits d'accès définitifs sont déterminés en prenant les droits les plus bas entre les droits résolus du jeu de données et les droits résolus du noeud.
Des droits d'accès spécifiques peuvent être définis au niveau du noeud. Si aucun droit d'accès spécifique n'est défini, le droit d'accès par défaut est utilisé pour le processus de résolution.
Note:
La procédure de résolution diffère légèrement entre les tables et leurs noeuds enfants.

Cas particulier des tables et noeuds de tables

Cette section décrit le processus de résolution utilisé pour un noeud de table donné ou un enregistrement N de la table.
Pour chaque règle de permission définie par l'utilisateur correspondant à un des profils de l'utilisateur, les droits d'accès pour N seront soit :
  1. Les droits d'accès définis localement pour N ;
  2. Hérités des droits d'accès définis dans le noeud de table ;
  3. Hérités des droits d'accès par défaut pour les valeurs du jeu de données.
Toutes les règles de permission correspondantes définies par l'utilisateur sont utilisées pour résoudre les droits d'accès pour N. La résolution est effectuée en fonction de la politique de restriction.
Les droits d'accès résolus définitifs seront les plus bas entre l'espace de données, le jeu de données et le droit d'accès résolu pour N.

Résolution des règles programmatiques

Il existe trois niveaux de résolution pour les règles de droit d'accès programmatiques : le jeu de données, l'enregistrement et le noeud. Puisqu'une seule règle d'accès programmatique peut être configurée pour un niveau donné, la dernière règle configurée sera celle utilisée par la procédure de résolution.

Résolution de règle sur jeu de données

Pour un jeu de données, la dernière règle est considérée comme la règle résolue.

Résolution de règle sur enregistrement

Pour un enregistrement, la règle résolue est la plus basse entre la règle résolue configurée sur le jeu de données et la règle configurée sur cet enregistrement. Voir SchemaExtensionsContext.setAccessRuleOnOccurrence pour plus d'informations.

Résolution de règle sur noeud

Pour un noeud enfant d'un enregistrement, la règle résolue est la plus basse entre la règle résolue sur l'enregistrement et la règle configurée pour ce noeud.
Pour un noeud enfant d'un jeu de données, la règle résolue est la plus basse entre la règle résolue configurée sur le jeu de données et la règle configurée sur ce noeud. Voir SchemaExtensionsContext.setAccessRuleOnNode pour plus d'informations.

Politique d'affichage pour les menus déroulant des clés étrangères

Si un enregistrement est masqué du fait des règles d'accès, il n'apparaîtra pas dans le menu déroulant des clés étrangères.
Attention:
Les droits d'accès résolus sur un jeu de données ou un noeud de jeu de données sont les droits minimum entre les droits d'accès résolus définis dans l'interface utilisateur et les règles programmatiques résolues, le cas échéant.

Résolution de permissions pour les services

Les services utilisateurs permettent d'exécuter des fonctions spécifiques et avancées à partir de l'interface utilisateur. Selon leur définition, ces services peuvent être appelés depuis un menu, comme action dans un workflow, comme item de perspective, ou encore être exécutés directement depuis une URL comme composant web.
Voir aussi:
Les permissions d'un service sont résolues dés lors que celui-ci est sollicité dans l'interface utilisateur, c'est à dire :
  • Lors de son exécution, juste avant l'affichage du service.
    Si la permission résolue dans le contexte pour l'utilisateur n'est pas enabled, un message d'interdiction s'affiche à la place du service.
  • Lors de l'affichage des menus si le service est défini comme affichable dans les menus.
    Si la permission résolue dans le contexte pour l'utilisateur n'est pas enabled, le service n'apparaît pas dans le menu.
Ainsi, à chaque sollicitation la résolution de permissions d'un service se déroule de la manière suivante, dans l'ordre et tant que les conditions sont respectées :
  1. L'activation du service doit correspondre au contexte courant. Cette activation tient compte :
  2. Lorsque le service est activé pour le contexte courant, les permissions pour la session utilisateur sont alors évaluées :

Résolution des règles utilisateur

Exemple

Dans cet exemple, nous avons deux utilisateurs appartenant à différents rôles et profils :
Utilisateur
Profils
Utilisateur 1
  • utilisateur1
  • rôle A
  • rôle B
Utilisateur 2
  • rôle C
  • rôle D
Les permissions associées aux rôles et aux profils au niveau du jeu de données sont les suivantes :
Profil Service prédéfini de création (@creation) Service prédéfini de duplication (@duplicate) Service prédéfini de comparaison (@compare) Service personnalisé 1 ( custom1) Service personnalisé 2 ( custom2) Politique de restriction
utilisateur1 Activé Désactivé Activé Désactivé Activé Non
Rôle A Activé Activé Désactivé Activé Désactivé Oui
Rôle B Activé Désactivé Activé Activé Désactivé Oui
Rôle C Activé Activé Désactivé Désactivé Désactivé Non
Rôle D Activé Désactivé Désactivé Activé Désactivé Non
Les services disponibles pour chaque utilisateur après la résolution des droits sont les suivantes :
Utilisateurs Services disponibles
Utilisateur 1 Service prédéfini de création (@creation)
Service personnalisé 1 ( custom1)
Utilisateur 2 Service prédéfini de création (@creation)
Service prédéfini de duplication (@duplicate)
Service personnalisé 1 ( custom1)
Voir aussi:

Résolution de permissions pour les actions

Les actions sont les opérations bas-niveau de manipulation d'objets EBX® sur lesquels il est possible de spécifier les droits d'exécution pour un profil. A la différence des permissions sur services utilisateurs, qui ne concernent que l'interface utilisateur, ces droits sont également applicables lorsqu'une opération est effectuée programmatiquement (c'est à dire via une Procedure) ou indirectement (par exemple lors d'un import de données, les actions sur table (création, surcharge, occultation et suppression) sont évaluées).
Voici la liste des actions sur lesquelles des droits sont définissables :
Objet de l'action Actions disponibles
Espace de données Créer un espace de données enfant
Créer une image
Initier une fusion
Exporter une archive
Importer une archive
Fermer l'espace de données
Fermer l'image
Créer un jeu de données
Jeu de données Dupliquer le jeu de données
Supprimer le jeu de données
Activer/désactiver le jeu de données
Créer une vue
Table Créer un nouvel enregistrement
Surcharger des enregistrements
Occulter des enregistrements
Supprimer des enregistrements
Pour la résolution des permissions sur actions, seules les permissions définies via l'interface utilisateur pour l'utilisateur courant (ou ses rôles) sont prises en compte, la politique de restriction s'appliquant comme pour toute permission définie via l'interface utilisateur.
Pour plus d'informations, se reporter à la section Résolution des règles utilisateur ci-après.

Résolution des règles utilisateur

Exemple

Dans cet exemple, nous avons deux utilisateurs appartenant à différents rôles et profils :
Utilisateur
Profils
Utilisateur 1
  • utilisateur1
  • rôle A
  • rôle B
Utilisateur 2
  • rôle C
  • rôle D
Les droits associés aux rôles et aux profils sur les actions d'une table donnée sont les suivants :
Profil Créer un enregistrement Surcharger un enregistrement Occulter un enregistrement Supprimer un enregistrement Politique de restriction
utilisateur1 Non Oui Non Oui Non
Rôle A Oui Non Oui Non Oui
Rôle B Non Oui Oui Non Oui
Rôle C Oui Non Non Non Non
Rôle D Non Non Oui Non Non
Les actions disponibles pour chaque utilisateur après la résolution des droits sont les suivantes :
Utilisateurs Actions disponibles
Utilisateur 1 Occulter un enregistrement
Utilisateur 2 Créer un enregistrement
Occulter un enregistrement
Voir aussi: