Les permissions définissent l'accès aux données et les actions disponibles pour chaque utilisateur.
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
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.
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.
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.
Dans l'API Java, la classe SessionPermissions permet d'accéder aux permissions résolues.
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)
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.
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.
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.
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.
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).
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.
Tous les niveaux utilisent un schéma similaire, qui permet la définition de règles de permission pour les profils.
Pour un espace de données, les permissions administrables pour chaque profil sont les suivantes :
Mode | Autorisation |
|---|---|
Écriture |
|
Lecture seulement |
|
Masqué |
|
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. |
Pour un jeu de données, les permissions administrables pour chaque profil sont les suivantes :
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. |
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. |
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. |
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 |
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 :
les AccessRule, décrites ci-après dans la section Définition des règles d'accès aux données.
les ServiceActivationRule, décrites ci-après dans la section Définition des règles d'activation sur service.
les ServicePermissionRule, décrites ci-après dans la section Définition des règles de permission sur service.
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 :
Création d'une règle sous la forme d'une classe Java implémentant l'interface AccessRule ou AccessRuleForCreate.
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.
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.
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 :
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.
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.
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 :
Création d'une règle sous la forme d'une classe Java implémentant l'interface ServicePermissionRule.
Assignation de cette règle aux services concernés :
Soit, pour les nouveaux services, au niveau de leur déclaration via la méthode ActivationContext.setPermissionRule.
La règle ainsi assignée est dite "globale", et est exécutée dés lors que le service est activé pour le contexte courant. Voir Résolution de permissions pour les services pour plus d'informations.
Soit, pour les services existants, dans l'extension du schéma via les méthodes SchemaExtensionsContext.setServicePermissionRuleOnNode et SchemaExtensionsContext.setServicePermissionRuleOnNodeAndAllDescendants. Il est ainsi possible d'assigner une règle à n'importe quel service, y compris les services standards fournis par EBX®, sur un ou plusieurs noeuds du modèle de données : un noeud table, un noeud d'association, etc.
La règle ainsi assignée est dite "locale" et n'est exécutée que dans le contexte du schéma étendu et lorsque le noeud concerné est celui spécifié. Voir Résolution de permissions pour les services pour plus d'informations.
Une seule ServicePermissionRule peut être définie pour chaque noeud du modèle. Ainsi, la définition d'une nouvelle règle programmatique remplacera l'existante.
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.
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.
Dans cet exemple, trois utilisateurs appartiennent aux rôles définis et profils suivants :
Utilisateur | Profil |
|---|---|
Utilisateur 1 |
|
Utilisateur 2 |
|
Utilisateur 3 |
|
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 |
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é.
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.
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.
La procédure de résolution diffère légèrement entre les tables et leurs noeuds enfants.
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 :
Les droits d'accès définis localement pour N ;
Hérités des droits d'accès définis dans le noeud de table ;
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.
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.
Pour un jeu de données, la dernière règle est considérée comme la règle résolue.
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.
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.
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.
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.
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.
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 :
L'activation du service doit correspondre au contexte courant. Cette activation tient compte :
du type d'entité sélectionnée (jeu de données, table, enregistrement, etc.) ;
des règles statiques d'activation définies au sein de la méthode UserServiceDeclaration.defineActivation;
de l'éventuelle règle dynamique d'activation (ServiceActivationRule) également définie au sein de la méthode UserServiceDeclaration.defineActivation.
Lorsque le service est activé pour le contexte courant, les permissions pour la session utilisateur sont alors évaluées :
Si des permissions ont été définies via l'interface utilisateur pour l'utilisateur courant (ou ses rôles), leur résolution doit retourner enabled.
Pour plus d'informations, se reporter à la section Résolution des règles utilisateur ci-après.
Si une règle de permission globale est définie pour le service, elle doit retourner enabled pour le contexte fourni (voir ServicePermissionRuleContext).
Si une règle de permission locale est définie pour le noeud sélectionné, elle doit retourner enabled pour le contexte fourni (voir ServicePermissionRuleContext).
Dans cet exemple, nous avons deux utilisateurs appartenant à différents rôles et profils :
Utilisateur | Profils |
|---|---|
Utilisateur 1 |
|
Utilisateur 2 |
|
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 ( | Service prédéfini de duplication ( | Service prédéfini de comparaison ( | Service personnalisé 1 ( | Service personnalisé 2 ( | 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) |
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.
Dans cet exemple, nous avons deux utilisateurs appartenant à différents rôles et profils :
Utilisateur | Profils |
|---|---|
Utilisateur 1 |
|
Utilisateur 2 |
|
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 |