Rôles et permissions
Un rôle répond à deux questions : ce que ses titulaires peuvent ouvrir (menus, requêtes, tableaux de bord, assistant) et quelles lignes ils voient. Les utilisateurs reçoivent des rôles ; un utilisateur qui a plusieurs rôles en cumule les droits.
Les rôles se modifient dans Liberty Next → Administrer → Accès → Roles. La liste des rôles est à gauche ; le rôle sélectionné s'ouvre dans un panneau à deux onglets : Access et Data scope.
Cette page traite des rôles de Liberty Next lui-même. Les rôles de JD Edwards EnterpriseOne et leur sécurité se gèrent dans Nomajde.
Vue d'ensemble
L'onglet Access
Point de départ
| Choix | Signification |
|---|---|
| No access | Rien, plus ce qui est autorisé en dessous (nothing, plus what you allow below). |
| Full access | Tout, moins ce qui est refusé en dessous (everything, minus what you deny below). La carte du rôle porte l'étiquette Full access. |
L'arborescence des menus
Le bloc Menus affiche le menu latéral de chaque application, un bloc par application (sales · 4 of 6 shown). Chaque dossier et chaque entrée porte un contrôle à trois états :
| Contrôle | Effet |
|---|---|
| Inherit (–) | Le nœud prend l'état de son dossier, ou le point de départ. La ligne indique inherits: allowed / denied / no access. |
| Allow (✓) | Le nœud et tout ce qu'il contient sont accordés. |
| Deny (⊘) | Le nœud et tout ce qu'il contient sont refusés, même si une autre règle les accorderait. |
Un dossier se propage à ses enfants ; un enfant peut le contredire. Une entrée affiche en gris ce qu'elle exécute (sql:sales:orders_get, un tableau de bord…) : autoriser l'entrée accorde à la fois l'entrée de menu et ce qu'elle exécute. L'œil de chaque entrée donne l'aperçu du résultat : vert, l'entrée apparaît dans le menu latéral du titulaire ; barré, elle n'y apparaît pas.
Deux rôles types :
- Tout sauf le dossier Sécurité : Full access, puis Deny sur le dossier Sécurité.
- Seulement le dossier Rapports : No access, puis Allow sur le dossier Rapports.
Hors menus
Certains droits ne correspondent à aucune entrée de menu. Le bloc Au-delà des menus les ajoute sous forme de pastilles vertes (autorisation) ou rouges (refus) : choisir Allow ou Deny, le type, l'élément, puis Add.
| Type | Accorde |
|---|---|
| Connector (all queries) | Toutes les requêtes d'un connecteur. |
| Query | Une requête — pour un écran ouvert depuis un bouton ou un lien plutôt que depuis le menu. |
| API endpoint | Un endpoint d'un connecteur API. |
| Dashboard | Un tableau de bord. |
| Data Explorer | Un modèle de l'explorateur, ou tous les modèles d'une application — voir Explorateur de données. |
| nomaflow | Suivre les tâches (nomaflow:view) — les pages Tâches, Planning et Exécutions, les exécutions et leurs journaux ; Créer et modifier les tâches (nomaflow:edit) — créer, modifier, suspendre et reprendre des tâches ; exécute SQL et Python sans restriction de lignes. Voir Administration de Nomaflow. |
| Tâche | Une tâche Nomaflow, ou Toutes les tâches (job:*) : son entrée de menu et sa page — fichiers, paramètres, lancement, annulation, journaux de toutes les exécutions. Voir Lancer une tâche depuis le menu d'une application. |
| AI assistant | L'assistant. |
| Pattern (expert) | Une permission écrite à la main, comme sql:sales:report_*. |
Save enregistre le rôle ; Cancel abandonne les modifications. Le nom d'un rôle ne peut plus changer après sa création.
Périmètre de données — quelles lignes
L'onglet Data scope limite les lignes vues par un rôle, sur chaque écran, export, tableau de bord, rapport et réponse de l'assistant qui lit un connecteur SQL. Un rôle sans règle voit toutes les lignes.
Une règle
| Champ | Choix |
|---|---|
| Dictionary item ou Column name | Ce qui est restreint. Un élément du dictionnaire (CO — Company) atteint chaque colonne qui le porte, dans chaque requête ; un nom de colonne ne restreint que cette colonne. |
| Connector | Any connector, ou un seul connecteur — la règle ne dit alors rien des autres. |
| Fixed values ou From the user's attribute | Les valeurs autorisées, choisies dans la liste de l'élément quand il en a une ; ou un attribut de l'utilisateur (company), pour qu'un seul rôle serve toutes les sociétés — chaque utilisateur porte ses propres valeurs (voir Utilisateurs). |
| Exclude these values instead | Transforme la liste en exclusions : SY not in 00. Les valeurs vides restent visibles. |
| A query without this item | is unrestricted : une requête sans cette colonne n'est pas limitée par la règle. returns nothing : une telle requête ne renvoie aucune ligne pour ce rôle (étiquette deny if absent). |
Chaque règle s'affiche sur une ligne : Company (CO) in 00001, 00050, SY not in 00, Company (CO) = user.company. Un clic sur une ligne la charge dans le formulaire ; la corbeille la supprime. Les règles s'enregistrent avec le rôle.
Combinaison des règles
- Dans un rôle, les règles se cumulent : société 00001 et SY différent de 00.
- Entre les rôles d'un utilisateur, le plus ouvert l'emporte : un utilisateur titulaire de subsidiary et de group voit ce que voit group.
- Un rôle sans règle lève toute restriction pour ses titulaires.
- Les superutilisateurs ne sont jamais restreints.
Où le périmètre s'applique
- Lectures : chaque requête d'un connecteur SQL est filtrée sur le serveur, quel que soit l'appelant — écrans, exports, tableaux de bord, rapports, assistant.
- Écritures : créer, modifier ou supprimer une ligne hors périmètre est refusé (403).
- Non filtrés : les connecteurs API et les tâches Nomaflow, qui s'exécutent sans utilisateur.
Retrouver la colonne d'un élément
Une colonne de requête porte un élément du dictionnaire quand l'écran l'indique, quand elle porte le nom de l'élément, ou — sur un connecteur doté d'un Dd Prefix (JD Edwards : 2) — quand son nom sans le préfixe de table est l'élément : ABCO, MCCO et SDCO portent tous CO. Une jointure de deux tables restreint les deux colonnes. Sur un pool qui supprime les espaces des textes de longueur fixe (JD Edwards), les valeurs sont comparées sans espaces.
Prise d'effet d'une modification
Le périmètre est calculé à la connexion et accompagne la session. Un changement de rôle ou d'attribut s'applique au renouvellement de la session — dans l'heure, ou aussitôt après une déconnexion et une reconnexion. La fenêtre Profil montre à chaque utilisateur ses attributs et son périmètre de données en clair.
Sans l'éditeur
Les mêmes règles se définissent avec liberty-admin set-scope et set-attributes (CLI), ou dans auth.toml :
[roles.subsidiary]
permissions = ["menu:sales:*", "sql:sales:*"]
scope = [
{ dd = "CO", source = "#USER.company#", mode = "deny" },
{ dd = "SY", values = ["00"], exclude = true },
]
Contrôle des permissions
Chaque permission est une chaîne séparée par des deux-points — menu:sales:orders, sql:sales:orders_get, dashboard:sales_overview, ai:chat — et l'éditeur les écrit de lui-même. Pour une requête, Liberty Next prend toutes les permissions de tous les rôles de l'utilisateur, puis :
- un superutilisateur est toujours autorisé ;
- un refus correspondant bloque — un refus dans un rôle l'emporte sur une autorisation dans un autre ;
- une autorisation correspondante accorde ;
- sinon, refusé.
* remplace un segment, ou tout le reste quand il termine la chaîne (sql:sales:*).
Pièges fréquents
| Situation | Explication |
|---|---|
| Un utilisateur voit encore un menu après la modification de son rôle | La session porte les droits : se déconnecter et se reconnecter, ou attendre le renouvellement (dans l'heure). |
| Un refus prévu pour un rôle en bloque un autre | Les refus s'appliquent à tous les rôles de l'utilisateur. Préférer No access plus des autorisations pour les rôles restreints. |
| Une requête du rôle ne renvoie rien | Une règle en mode returns nothing, et la requête n'a pas de colonne portant l'élément. Utiliser is unrestricted ou ajouter la colonne. |
| Un utilisateur soumis à une règle par attribut ne voit rien | L'utilisateur n'a pas de valeur pour cet attribut — voir Utilisateurs. |
| Les rôles ne peuvent pas être supprimés depuis l'éditeur | Retirer le rôle à ses utilisateurs ; un rôle inutilisé n'accorde rien. |