1C dispose d'un système intégré de droits d'accès (ce système est appelé rôles 1C). Ce système est statique - comme l'administrateur a défini les droits 1C, qu'il en soit ainsi.
De plus, il existe un système dynamique de droits d'accès (appelé RLS 1C). Dans celui-ci, les droits 1C sont calculés dynamiquement au moment du travail de l'utilisateur en fonction des paramètres spécifiés.
L'un des paramètres de sécurité les plus courants dans divers programmes est un ensemble d'autorisations de lecture / écriture pour les groupes d'utilisateurs, puis - l'inclusion ou l'exclusion d'un utilisateur des groupes. Par exemple, un système similaire est utilisé dans Windows AD (Active Directory).
Un tel système de sécurité dans 1C est appelé Rôles 1C. Rôles 1C se trouve dans la configuration dans la branche Général / Rôles. Les rôles 1C agissent comme des groupes auxquels des droits 1C sont attribués. En outre, l'utilisateur est inclus ou exclu de ce groupe.
En double-cliquant sur le nom du rôle 1C, vous ouvrez l'éditeur des droits du rôle 1C. Gauche - une liste d'objets 1C. Sélectionnez n'importe lequel et les options des droits d'accès seront affichées sur la droite (au moins: lire, ajouter, modifier, supprimer).
Pour la branche supérieure (le nom de la configuration actuelle), les droits d'administration 1C et l'accès pour lancer diverses options sont définis.
Tous les droits 1C sont divisés en deux groupes - le droit «simple» et le même droit avec l'ajout de «interactif». Qu'est-ce que ça veut dire?
Lorsqu'un utilisateur ouvre un formulaire (par exemple, le traitement) et clique sur un bouton, le programme dans le langage 1C intégré effectue certaines actions, par exemple la suppression de documents. Pour la permission de ces actions (exécutées par programme) - les droits 1C sont «juste» responsables.
Lorsqu'un utilisateur ouvre un magazine et commence à faire quelque chose à partir du clavier de lui-même (par exemple, entrer de nouveaux documents), il s'agit de droits 1C «interactifs».
Un utilisateur peut avoir plusieurs rôles disponibles, puis les autorisations sont ajoutées.
Une section des possibilités de définition des droits d'accès à l'aide des rôles - objet 1C. Autrement dit, vous pouvez activer l'accès au répertoire ou le désactiver. Vous ne pouvez pas l'allumer un peu.
Pour cela, il existe une extension du système de rôle 1C appelée 1C RLS. C'est un système dynamique de droits d'accès qui vous permet de restreindre l'accès en partie. Par exemple, un utilisateur ne voit que les documents d'un certain entrepôt et d'une organisation et ne voit pas le reste.
Soigneusement! Lors de l'utilisation d'un schéma RLS 1C déroutant, différents utilisateurs peuvent avoir des questions lorsqu'ils essaient de comparer le même rapport généré par différents utilisateurs.
Vous prenez un certain répertoire (par exemple, des organisations) et un certain droit (par exemple, lire). Vous autorisez la lecture pour le rôle 1C. Dans le panneau Restriction d'accès aux données, vous définissez le texte de la requête qui renvoie TRUE ou FALSE selon les paramètres. Les paramètres sont généralement stockés dans un registre d'informations (par exemple, le registre d'informations de configuration Comptabilité UserAccessPrivacy Settings).
Cette requête est exécutée dynamiquement (lors de la tentative d'implémentation de la lecture), pour chaque enregistrement de dictionnaire. Ainsi, pour les enregistrements pour lesquels la requête de sécurité a retourné TRUE - l'utilisateur verra, et le reste ne le verra pas.
Les droits 1C pour lesquels des restrictions RLS 1C sont définies sont surlignés en gris.
La copie des mêmes paramètres RLS 1C est effectuée à l'aide de modèles. Vous créez un modèle, nommez-le (par exemple) MyPattern, spécifiez une demande de sécurité dans celui-ci. De plus, dans les paramètres des droits d'accès 1C, spécifiez le nom du modèle comme ceci: "#MyTemplate".
Lorsqu'un utilisateur travaille en mode Entreprise 1C, lorsque RLS 1C est en cours d'exécution, il peut recevoir un message d'erreur «Droits insuffisants» (par exemple, pour lire le répertoire Xxx).
Cela signifie que RLS 1C a bloqué la lecture de plusieurs enregistrements.
Afin d'éviter qu'un tel message n'apparaisse, il est nécessaire d'utiliser le mot AUTORISÉ () dans le texte de la requête dans le langage 1C intégré.
Par exemple:
Problème classique: donner à l'utilisateur l'accès à un objet, mais pas à tous les éléments / documents, mais uniquement à certains.
Par exemple, pour le gestionnaire de voir les rapports uniquement pour ses clients.
Ou ça pourrait être une limitation "Tous sauf quelques-uns".
Ou la restriction ne concerne pas les répertoires / documents, mais sur les données du registre…
Par exemple, pour que les utilisateurs ne puissent pas extraire des données sur les paiements aux partenaires avec aucun rapport.
En fait, il s'agit d'un paramètre subtil et très flexible «ce qui peut être vu par cet utilisateur, et ce qu'il n'a pas besoin de deviner».
Pourquoi RLS?
La plupart des implémentations exigent que différents utilisateurs établissent différents niveaux d'accès aux informations de la base de données.
Dans les configurations, des objets de métadonnées spéciaux - les rôles - sont responsables des éventuels droits d'accès aux données. Chaque utilisateur de la base d'informations se voit attribuer un ou plusieurs rôles. Ils déterminent si des opérations sont possibles avec des objets de métadonnées spécifiques (lecture, écriture, conduite, etc.).
Mais ce n'est pas tout.
Il faut souvent non seulement ouvrir / refuser l'accès à un objet spécifique, mais restreindre l'accès à une partie des données qu'il contient.
Les rôles seuls ne peuvent pas résoudre ce problème. - pour cela, un mécanisme de restriction d'accès au niveau enregistrement (RLS) a été mis en œuvre.
Les restrictions sont les conditions dans lesquelles les actions sur les données (lecture, écriture, etc.) seront autorisées. - vous pouvez ainsi restreindre l'accès non pas à l'objet dans son ensemble, mais uniquement à une partie de ses données.
À propos de RLS - plus en détail: 8 vidéos et PDF
Puisqu'il s'agit d'une tâche courante pour administrer 1C, nous vous suggérons d'examiner des documents plus détaillés:
Restreindre l'accès aux données à l'aide de rôles
Cette vidéo explique comment restreindre l'accès aux données à l'aide de rôles. Il est spécifié que les rôles restreignent l'accès au type d'objets infobase (un répertoire séparé, mais pas des éléments spécifiques de l'annuaire).
Restriction de niveau d'enregistrement (RLS)
Cette vidéo décrit le mécanisme des restrictions d'accès au niveau de l'enregistrement (RLS), lorsque vous pouvez configurer l'accès non pas à tout le répertoire dans son ensemble, mais à ses éléments individuels, en fonction de ceux stockés dans la base de données d'informations. Ces restrictions sont écrites dans les rôles.
Mise en place de restrictions d'accès au niveau des enregistrements pour l'annuaire des entrepreneurs
Cette vidéo décrit comment configurer l'accès des gestionnaires uniquement à leurs propres sous-traitants qui leur sont affectés dans la configuration de démonstration de l'application gérée.
Fonctionnement des restrictions d'accès au niveau des enregistrements de bas niveau
Cette vidéo montre comment la plate-forme transforme les demandes envoyées au serveur SGBD pour exécution en cas de restrictions d'accès au niveau des enregistrements.
Combinaison de plusieurs restrictions d'accès au niveau de l'enregistrement
Un utilisateur d'infobase peut se voir attribuer plusieurs rôles. En même temps, chaque rôle peut avoir ses propres restrictions d'accès au niveau de l'enregistrement. Cette vidéo décrit le comportement du système lorsqu'il est imposé.
Contrainte avec la méthode ALL
Cette vidéo décrit la première façon d'imposer des restrictions au niveau de l'enregistrement - la méthode ALL. Dans ce cas, si la sélection comprend des enregistrements dont l'accès est limité, un message d'erreur s'affiche.
Imposer des restrictions à l'aide de la méthode ALLOW
Cette vidéo décrit la première façon d'imposer des restrictions au niveau de l'enregistrement - la méthode AUTORISÉE. Dans ce cas, seuls les enregistrements auxquels l'utilisateur a des droits d'accès seront inclus dans la sélection.
Voici quelques sujets du cours:
- Installation et mise à jour de la plateforme 1C: Enterprise 8 - manuel et automatique, pour Windows et Linux
- Démarrage automatique pour effectuer des opérations de routine
- Mise à jour des configurations depuis le mode utilisateur
- Mise à jour des configurations non standard. Comment éviter les problèmes lors de la mise à jour modification des configurations typiques
- Créer le vôtre fichiers de livraison cfu
- Outils BSP: formulaires externes, traitement du remplissage des documents, etc.
- En utilisant sGBD PostgreSQL gratuit
- Installation et lancement cluster de serveurs 1C: Entreprise 8
- Utilitaire d'administration pour configurer le cluster et les serveurs de production
- Personnalisation RLS sur l'exemple de SCP 1.3 et ERP 2
- Que faire, si les données dans IB sont corrompues
- Personnalisation l'échange de données entre les configurations
- Organisation développement de groupe
- Personnalisation et utilisation clés de protection matérielle
- Licences logicielles 1C: installation et liaison à un équipement externe
Dans tous les cas, il vous faudra un jour déployer 1C, configurer la redondance, les droits d'accès, différents modes de lancement, tester l'intégrité des bases de données, assurer le fonctionnement des serveurs, etc.
Et il vaut mieux le faire tout de suite.
Pour qu'il n'y ait pas «…! Eh bien ce que ...! Le tiens ...! " - et autres expressions de regret :)
Chaque dirigeant acceptera inconditionnellement que chaque salarié de l'entreprise ne devrait avoir accès qu'aux informations qui relèvent de sa compétence. Par exemple, un magasinier dans un entrepôt n'a pas besoin de regarder quelles opérations sont effectuées par le directeur financier ou le chef comptable. Cependant, des situations assez subtiles surviennent souvent, par exemple lorsque le programme 1C: Enterprise 8 est utilisé non pas pour une, mais pour plusieurs entreprises. Chacun d'eux a ses propres employés qui ne devraient avoir accès qu'aux informations autorisées relatives à leur entreprise.
Dans ce cas, l'assistant idéal pour garantir les droits d'accès nécessaires est la technologie Niveau de sécurité record (RLS), qui vous permet de fournir un accès aux informations au niveau de l'enregistrement.
Prenons un exemple de situation spécifique. Notre entreprise se compose de deux organisations. Le premier est engagé dans la vente de logiciels, dans le second - la formation pour travailler avec. Pour prendre en compte ces deux organisations, nous utilisons le produit logiciel 1C: Integrated Automation 8.
Notre tâche est de différencier les droits d'accès à l'information des employés de deux organisations afin que les employés ayant les mêmes droits ne puissent voir que ce qui est lié à l'organisation dans laquelle ils travaillent.
La première chose qui vient à l'esprit lors de la définition de cette tâche est la définition des sélections pour les organisations. Cependant, cette solution présente deux inconvénients importants:
- les sélections devront être configurées dans toutes les formes du programme;
- pour un utilisateur plus ou moins malin, il n'est absolument pas difficile de les désactiver.
Le moyen le plus sûr est de délimiter l'accès des utilisateurs au niveau de l'enregistrement. Comment cela peut-il être fait?
La première chose à faire est d'activer le programme pour utiliser cette méthode. Cela nécessite:
Dans notre cas, il est nécessaire d'introduire des restrictions d'accès par organisation, mais il est clair que le programme offre des opportunités beaucoup plus larges. Par exemple, pour délimiter l'accès par des ouvrages de référence et des documents.
Un mécanisme similaire est implémenté dans d'autres solutions appliquées 1C:
- (révision 10.3)
- et 1C: Gestion des salaires et du personnel 8 (version 2.5).
Dans ces programmes, la différenciation des droits d'accès se fait à l'aide du livre de référence «Groupes d'utilisateurs», disponible dans le menu «Service», rubrique «Paramètres d'accès des utilisateurs».
- Ainsi, dans ces programmes, nous devons diviser tous nos utilisateurs travaillant dans l'entreprise en groupes par organisation.
- Appuyez ensuite sur le bouton "Accéder aux paramètres".
- Dans la fenêtre qui apparaît, cliquez sur le bouton "Ajouter" et saisissez l'objet d'accès (dans notre cas, il s'agit d'une organisation).
- Si nous devons autoriser les employés de l'organisation à entrer des données dans la base de données d'informations, nous devons cocher la case dans la colonne «Enregistrer».
Ces étapes doivent être effectuées pour chaque organisation. Après cela, après être entré dans le programme, chaque employé ne verra que les documents qui sont déterminés par ses droits d'accès par poste et se rapportent à son organisation.
Le programme 1C dispose d'un système intégré de droits d'accès, qui se trouve dans Configurateur - Général - Rôles.
Qu'est-ce qui caractérise ce système et quel est son objectif principal? Il vous permet de décrire des ensembles de droits qui correspondent aux positions des utilisateurs ou aux types de leurs activités. Ce système de droits d'accès est de nature statique, ce qui signifie que, comme l'administrateur a défini les droits d'accès sur 1C, il l'est. En plus du système statique, il existe un deuxième système de droits d'accès - dynamique (RLS). Dans ce système, les droits d'accès sont calculés de manière dynamique, en fonction des paramètres spécifiés, pendant le fonctionnement.
Rôles dans 1C
Les paramètres de sécurité les plus courants dans différents programmes sont le soi-disant ensemble d'autorisations de lecture / écriture pour divers groupes d'utilisateurs et à l'avenir: inclusion ou exclusion d'un utilisateur spécifique des groupes. Un tel système, par exemple, est utilisé dans le système d'exploitation Windows AD (Active Directory). Le système de sécurité utilisé dans le logiciel 1C est appelé rôles. Ce que c'est? Rôles dans 1C est un objet situé dans la configuration dans la branche: Général - Rôles. Ces rôles 1C sont des groupes pour lesquels des droits sont attribués. À l'avenir, chaque utilisateur pourra être inclus et exclu de ce groupe.
En double-cliquant sur le nom du rôle, vous ouvrirez l'éditeur de droits du rôle. Sur la gauche se trouve une liste d'objets, marquez l'un d'entre eux et sur la droite, vous verrez des options pour les droits d'accès possibles:
- lecture: réception des enregistrements ou de leurs fragments partiels de la table de la base de données;
- ajout: de nouveaux enregistrements tout en sauvegardant les existants;
- changement: apporter des modifications aux enregistrements existants;
- suppression: certaines entrées, en gardant le reste inchangé.
Notez que tous les droits d'accès peuvent être divisés en deux groupes principaux - il s'agit d'un droit "simple" et d'un tel droit avec l'ajout de la caractéristique "interactive". Qu'est-ce que ça veut dire? Le point est le suivant.
Dans le cas où l'utilisateur ouvre un formulaire, par exemple, le traitement, et clique en même temps dessus avec la souris, le programme dans le langage 1C intégré commence à effectuer des actions spécifiques, en supprimant des documents, par exemple. Pour l'autorisation de telles actions effectuées par le programme, les droits 1C "simples" correspondants sont responsables.
Dans le cas où un utilisateur ouvre un magazine et commence à saisir quelque chose de lui-même à partir du clavier (nouveaux documents, par exemple), alors les droits "interactifs" 1C sont responsables de permettre de telles actions. Chaque utilisateur peut avoir plusieurs rôles disponibles à la fois, puis l'autorisation est ajoutée.
RLS en 1C
Vous pouvez activer l'accès au livre de référence (ou au document) ou le désactiver. Dans le même temps, il est impossible «d'en inclure un peu». À cette fin, il existe une certaine extension du système de rôle 1C, appelée RLS. Il s'agit d'un système dynamique de droits d'accès, qui introduit des restrictions partielles d'accès. Par exemple, seuls les documents d'une certaine organisation et d'un certain entrepôt deviennent disponibles à l'attention de l'utilisateur, il ne voit pas le reste.
Il convient de garder à l'esprit que le système RLS doit être utilisé avec beaucoup de prudence, car son schéma déroutant est assez difficile à comprendre, tandis que différents utilisateurs peuvent avoir des questions lorsqu'ils vérifient, par exemple, le même rapport, qui est généré à partir de sous différents utilisateurs. Prenons un exemple. Vous sélectionnez un annuaire spécifique (organisations, par exemple) et un droit spécifique (lecture, par exemple), c'est-à-dire que vous autorisez la lecture pour le rôle 1C. Dans le même temps, dans le panneau Restrictions d'accès aux données à distance, vous définissez le texte de la demande, selon lequel False ou True est défini, en fonction des paramètres. En règle générale, les paramètres sont stockés dans un registre d'informations spécial.
Cette requête sera exécutée dynamiquement (lors d'une tentative d'organisation de la lecture) pour tous les enregistrements du dictionnaire. Cela fonctionne comme ceci: les enregistrements auxquels la requête de sécurité a été attribuée - Vrai, l'utilisateur verra, et d'autres non. Les droits 1C avec des restrictions établies sont surlignés en gris.
L'opération de copie des mêmes paramètres RLS est effectuée à l'aide de modèles. Tout d'abord, vous créez un modèle, en l'appelant, par exemple, MyTemplate, dans lequel vous reflétez la demande de sécurité. Ensuite, dans les paramètres des droits d'accès, spécifiez le nom de ce modèle de cette manière: "#MyTemplate".
Lorsqu'un utilisateur travaille en mode 1C Entreprise, lors de la connexion à RLS, un message d'erreur de la forme: "Droits insuffisants" (pour lire le répertoire XXX, par exemple) peut apparaître. Cela indique que le système RLS a bloqué la lecture de certains enregistrements. Pour éviter que ce message ne réapparaisse, vous devez saisir le mot AUTORISÉ dans le texte de la demande.
L'astuce fournit des instructions pas à pas pour la configuration de Record Level Sceurity (RLS) dans Axapt 3.0.
Où est-il écrit dans la documentation
Version russe: Guide de l'utilisateur pour l'administrateur (russe) _3.0.pdf (p. 126)
Version anglaise: Guide de l'utilisateur pour l'administration (p. 40, 101)
introduction
La restriction des droits au niveau de l'enregistrement (Record Level Security - RLS) vous permet de restreindre l'accès aux enregistrements pour différents groupes d'utilisateurs. Par exemple, un groupe de gestionnaires peut voir des clients russes, tandis qu'un autre peut voir des clients étrangers. De plus, les gestionnaires travaillant avec des clients russes ne devraient pas voir de clients étrangers. De plus, les managers ne devraient même pas les voir.
RLS dans Axapta fonctionne en conjonction avec le système de paramétrage des droits personnalisés. Cela signifie que pour restreindre l'accès à un champ particulier d'une table, vous devez définir des droits normaux sur ces tables. La tâche de RLS est de filtrer les enregistrements que l'utilisateur ne remarque pas.
La mise en place de restrictions de droits au niveau de l'enregistrement revient à définir des filtres pour certaines tables pour différents groupes d'utilisateurs. Si l'utilisateur appartient à plusieurs groupes, les filtres sont combinés par la condition OR.
L'art de configurer les permissions est de définir les bons filtres sur les bonnes tables. Et de le faire de manière optimale pour ne pas réduire les performances du système.
Personnalisation
Avant de procéder à la configuration de la restriction des droits d'accès, il est nécessaire de prendre des mesures préliminaires:
Les travaux préparatoires sont terminés. Actuellement, l'utilisateur Test n'a aucun droit. Vous pouvez accéder à Axapta sous l'utilisateur de test et vous assurer qu'il ne peut même pas ouvrir le menu principal.
Vous pouvez commencer à configurer RLS:
- Configurons les droits normaux pour le groupe tstGroup1.
- Cliquez sur le bouton Request;
À proprement parler, tout! RLS est configuré. Désormais, l'utilisateur Test a le droit de lire les données du module Comptes clients et le droit de créer et de supprimer des commandes. De plus, un filtre est appliqué à la table des clients. Désormais, les utilisateurs appartenant au groupe tstGroup1 ne pourront voir que les autres clients (clients pour lesquels le groupe Autre est défini).
Vérifiez le réglage
Connectez-vous à Axapta sous l'utilisateur Test. Ouvrez la liste des clients (Menu principal \\ Comptes avec clients \\ Clients). Assurez-vous que la liste des clients n'affiche que les clients pour lesquels le groupe avec le code Prch est défini.
Veuillez noter que non seulement l'onglet Comptes clients a été ouvert dans le menu principal. Les onglets Grand livre, Trésorerie, CRM, Gestion des stocks, Général sont également ouverts. Le fait est qu'en accordant les droits au module clients, nous avons affecté de nombreuses tables d'autres modules. Oui, bien sûr, les signets inutiles sont presque vides. Mais tout de même, dans la vraie vie, les droits devraient être accordés avec beaucoup plus de précision.
De plus, dans la vraie vie, les signets des modules non achetés n'apparaissent jamais. Par exemple, essayez de désactiver le module CRM dans le paramètre des clés de configuration.
Essayez d'appliquer le filtre "*" au groupe (Placez la souris sur la colonne Groupe de clients, cliquez avec le bouton droit, sélectionnez Rechercher ..., entrez le filtre "*").
Essayez également d'appliquer le filtre "! Prc". Essayez de filtrer d'autres champs. Assurez-vous que le filtre client fonctionne correctement dans tous les cas.
Découvrez comment RLS fonctionne dans les rapports. Ouvrez le rapport avec la liste des clients (Menu principal \\ Comptes clients \\ Rapports \\ Données de base \\ Client). Essayez de créer le même rapport avec des filtres. Assurez-vous que le filtre client fonctionne également correctement dans vos rapports.
Veuillez noter que le programmeur n'a pas besoin de changer ou d'altérer quoi que ce soit pour que RLS fonctionne dans son rapport, s'il a utilisé le noyau dans des formulaires ou pour créer des rapports et n'a pas remplacé le mécanisme de récupération de données. Si le programmeur a codé manuellement les requêtes, il doit alors ajouter un appel à la méthode recordLevelSecurity (true) pour les tables où il est nécessaire d'activer la restriction d'accès aux enregistrements. Consultez le guide du développeur pour le mot clé Record Level Security pour plus de détails.
Commandes ouvertes. Oups! Et les commandes sont affichées pour tous les clients. Pourquoi? Parce que les commandes contiennent des codes clients, pas les clients eux-mêmes. Essayez d'aller à la table principale avec les clients - vous ne pourrez pas voir les paramètres des clients cachés.
De manière générale, dans la vraie vie, il ne suffit pas de configurer une seule table pour définir une restriction au niveau d'accès. En règle générale, des contraintes interdépendantes doivent être imposées à plusieurs tables liées.
Les droits d'accès au niveau des enregistrements s'appliquent non seulement aux formulaires et aux rapports, mais également aux listes déroulantes. Ouvrez la commande et cliquez sur le bouton de la liste déroulante du client. Oui tout est correct. L'utilisateur Test ne voit que les autres clients.
RLS pour plusieurs groupes
Considérons maintenant une situation où vous devez configurer plusieurs groupes différents avec des droits différents et avec des restrictions de droits différentes.
Supposons qu'un groupe de gestionnaires a accès aux autres clients (groupe de clients \u003d O&M) et qu'un autre groupe de gestionnaires a accès aux clients normaux (groupe de clients \u003d T&L). Nous avons déjà configuré le premier groupe. Il reste à configurer le deuxième groupe.
Répétez les étapes 8 à 10. Il suffit de définir les droits complets du groupe tstGroup2 sur le module Comptes clients et de spécifier "T&U" comme critère dans le paramètre RLS pour le groupe tstGroup2.
Pour vérifier, accédez à Axapta sous l'utilisateur Test et assurez-vous que les formulaires et les rapports fonctionnent correctement, assurez-vous que vous avez reçu tous les droits sur les clients et pouvez modifier les paramètres du client.
Que se passe-t-il si un client change de groupe? Dans le formulaire, le client sera visible jusqu'à ce qu'il quitte le formulaire écran. Dès qu'Axapta relira les données du serveur, RLS fonctionnera et le gestionnaire ne verra plus le client "étranger".
Cet exemple montre à nouveau que les droits doivent être configurés de manière complexe. Dans cette situation, vous pouvez soit empêcher les responsables de modifier le champ Groupe de clients, soit configurer une restriction au niveau de l'enregistrement (RLS) et sur la table avec des groupes.
Pour que certains utilisateurs autorisent l'accès à la liste complète des clients, il est nécessaire de donner au troisième groupe des droits sur la table des clients, mais pas de configurer RLS. Axapta examine les autorisations normales. Et, si vous avez le droit d'accès, il examine les paramètres RLS. S'il n'y a pas de paramètres RLS pour ce groupe et cette table, Axapta affiche tous les enregistrements de la table.
Notez que le groupe tstGroup3 n'affectait pas le comportement RLS tant qu'il n'avait pas les droits sur la table clients. Dès l'apparition du droit aux clients dans ce groupe, ce groupe s'est immédiatement impliqué dans RLS. Pour tester cette thèse, supprimez les droits sur le module Comptes clients dans le groupe tstGroup2 et vérifiez le RLS pour le client Test. Vous ne verrez que d'autres clients.
