Rowaccess - Droits d'accès aux données avec SFK
- Philippe MEYER
- Bertrand Littel
SOMMAIRE
Rowaccess c’est quoi ?
Le Framework SFK fournit un mécanisme qui permet de filtrer l’accès aux données.
Ce mécanisme est comparable à la mécanique de filtre de synchro du Mobile.
On va ainsi fournir un moyen de construire la liste des éléments accessibles pour un utilisateur connecté.
Comment fonctionne le rowaccess ?
Stockage en base de données
Deux tables systèmes contiennent les informations nécessaires pour la gestion des droits d’accès.
Il fortement déconseillé d’utiliser manuellement les tables systèmes dans les requêtes métier.
sw_sys_rowaccessstatus
Liste les demandes de calculs de droits d’accès
Nom de colonne | Type | Description |
|---|---|---|
device_ID | INT(11) | ID du compte de l’utilisateur dont on a demandé les droits d’accès |
metatable_ID | INT(11) | ID de la table pour laquelle on gère les droits |
computeDate | DATETIME | Date de calcul de droits d’accès |
computeDuration | INT(11) | Durée de calcul en millisecondes |
Liste les tables ayant un calcul de rowaccess (en comptant le nombre de comptes)
SELECT
ras.metatable_ID, mt.schemaTable, COUNT(ras.device_ID) AS nbDevice
FROM sw_sys_rowaccessstatus AS ras
INNER JOIN sw_sys_metatable AS mt
ON mt.metatable_ID = ras.metatable_ID
GROUP BY ras.metatable_ID;sw_sys_rowaccess
Liste les éléments pour lesquelles l’utilisateur a le droit d’accéder
Nom de colonne | Type | Description |
|---|---|---|
device_ID | INT(11) | ID du compte de l’utilisateur |
metatble_ID | INT(11) | ID de la table |
rowID | BIGINT(20) | ID de l'élément pour lequel dans la table donnée le compte de l’utilisateur a accès |
Liste les tables et comptes ayant des rowaccess (en comptant le nombre d'éléments accessibles par table) :
SELECT
ra.metatable_ID, mt.schemaTable, ra.device_ID, d.name, COUNT(1) AS nbRowAccess
FROM sw_sys_rowaccess AS ra
INNER JOIN sw_sys_metatable AS mt
ON mt.metatable_ID = ra.metatable_ID
INNER JOIN sw_sys_device AS d
ON d.device_ID = ra.device_ID
GROUP BY ra.metatable_ID, ra.device_ID;Calcul de rowaccess
Le rowaccess est lié à une table.
Le calcul est lancé pour un compte connecté.
Pour construire la liste des rowID, il faut utiliser un datasource de type “rowaccess”.
Avec les 3 propriétés suivantes
Nom de propriété | Description | Remarque |
|---|---|---|
TableName | Nom de la table pour laquelle on calcule les droits d’accès | Le format avec SFK n’a pas besoin du préfix sw_data_ (exemple : “customer”) |
RowIdField | Nom du champ qui contient l’ID que l’on va copier dans sw_sys_rowaccess.rowID |
|
SelectQueryName | Nom du fichier contenant la requête SQL qui retourne la liste des ID accessibles de la table pour un compte | Il est possible de filtrer par rapport à différentes informations liées au compte connecté en utilisant les variables système deviceID, baseUser, baseUserTree, … et les variables de session |
Pour demander le calcul d’un rowaccess, il faut utiliser une des méthodes de script client suivantes
$rowAccess.setByDatasourceAsync(datasourceName: string, forceUpdate?: boolean = false)
Pour calculer les droits d’accès avec un datasource.$rowAccess.setByDatasourcesAsync(datasourceNames: string[], forceUpdate?: boolean = false)
Pour calculer les droits d’accès avec plusieurs datasource.
Note : attention s’il y a des dépendances entre 2 rowaccess, il ne faut pas les calculer ensemble (exemple : customercontact dépend de customer)
SFK a un mécanisme pour éviter la surcharge du serveur avec des demandes de calcul trop fréquentes.
S’il y a moins de 5 minutes entre une demande de calcul et la précédente, alors SFK refuse le calcul de droit d’accès. La propriété optionnelle foreceUpdate permet d’obliger le recalcul.
En standard, à la connexion (aussi valable avec F5), on utilise la demande de calcul sans forcer. Par contre lors d’une création ou avec à l’utilisation du bouton de la barre de notification qui permet de mettre à jour les droits d’accès, on force le calcul.
Bouton pour forcer le recalcul de rowaccess
Pour un projet, il est possible d’activer un bouton dans la barre de notification avec la variable RowAccess.ManualRefresh.Enabled.
Bouton pour forcer le recalcul des droits d’accès
Ce bouton permet de lancer un recalcul manuel sans tenir compte du délai du cache de tous les rowaccess.
Ce bouton est disponible depuis la version 5.5.
Application du rowaccess
A partir du moment où l’on a une demande de calcul dans la table sw_sys_rowaccessstatus pour une table, cette table sera alors soumise à un droit d’accès. Et tous les comptes qui n’ont pas de ligne pour la table dans sw_sys_rowaccess n’ont aucun accès pour cette table.
Note : c’est valable aussi pour les comptes externes (Extranet). Donc lorsqu’on ajoute un rowaccess, il faut s’assurer que les comptes externes ne sont pas altérés.
Le rowaccess est donc automatiquement géré par le Framework SFK.
Il y a un contrôle d’accès à
un formulaire (crud)
Si le crud utilise un datasource de type “table” dont la table est soumise à un rowaccess, les droits d’accès sont automatiquement gérés. Il faut alors avoir accès à l’ID pour que les données soient chargées dans le formulaire.dans n’importe quel datasource avec une requête SQL (utilisé par une grid, un graph, une combobox, …)
Si l’on utilise la syntaxe {{TABLE(<nom_de_table>, <alias_de_table>)}} avec une table soumise à un rowaccess alors la requête va intègrer un filtre avec sw_sys_rowaccess.
Note : la syntaxe peut être utilisé pour les clauses FROM et INNER JOIN.un élément dans une liste d’entité (entityviews)
Si l’entité est une table soumise à un rowaccess, alors la requête pour construire la liste va intégrer un filtre avec sw_sys_rowaccess.
Si la propriété Data.ApplyRestrictions est utilisée sur une colonne de type foreign dont le schema est définit sur une table soumise à un rowaccess alors la requête pour construire la liste va intégrer un filtre avec sw_sys_rowaccess.
Vider le rowaccess
On peut retirer l'ensemble des rowaccess (gestion de cache pris en compte).
Cette capacité est réservé à un compte connecté ayant le droit isAdmin.
/api/rowaccess/clear
Permet de vider l’ensemble des rowaccess pour un projet.
/api/rowaccess/clear/table_name
Permet de supprimer les rowaccess d’une table pour un projet.
Note : le format avec SFK n’a pas besoin du préfix sw_data_ (exemple : /api/rowaccess/clear/customer)
Comment modifier sur mon projet le calcul d’un rowaccess ?
Identifier le(s) datasource de type “rowaccess” avec le TableName correspondant à la table pour laquelle on veut modifier les règles de droits d’accès.
Modifier la requête pour appliquer des règles spécifiques au projet.
Note : ne pas oublier d’utiliser les variables système et de session pour filtrer.
Comment ajouter sur mon projet un nouveau rowaccess ?
Ajouter un datasource de type “rowaccess” pour une table dont on veut gérer les droits d’accès.
Utiliser ce datasource avec une des fonctions $rowAccess.setByDatasourceAsync ou $rowAccess.setByDatasourcesAsync
dans le script/méthode d’entrée de l’application identifiable dans le fichier project.settings dans la section Events.ApplicationLoad (le plus souvent c’est “Global_OnLogin”). Cela permet de calculer les rowaccess à la connexion ou lorsque l’utilisateur fait F5.
dans un script/méthode après l’insertion d’un élément pour que l’utilisateur puisse immédiatement y accéder.
Comment désactiver sur mon projet un rowaccess ?
Il faut retirer toutes les occurrences des fonctions $rowAccess.setByDatasourceAsync et $rowAccess.setByDatasourcesAsync utilisant le(s) datasource de type “rowaccess” avec le TableName correspondant à la table pour laquelle on veut désactiver.
Ne pas oublier de vider le rowacess pour la table après avoir désactivé.
La désactivation d'un rowaccess, c’est retirer une restriction d’accès pour tous les utilisateurs d’un projet. Sans restriction, tous les utilisateurs vont accéder à toutes les données.
Si on veut continuer à avoir une restriction sans utiliser le rowaccess, c’est possible, mais il faut pour
toutes les listes utilisant la table, ajouter des filtres afin de réduire l’accès en fonction de l’utilisateur connecté
tous les formulaires, mettre en place une condition d’accès à la page qui se base sur l’ID du formulaire
Historique d’utilisation
Ce mécanisme est mis à disposition par le Framework SFK depuis février 2021.
Il a d’abord été intégré pour filtrer l’accès au tiers (table sw_data_customer) dans les versions suivantes de weavy 5.3, 5.4, 5.5, 5.6 et 5.7.
Il a été identifié comme une capacité nécessaire au filtrage des données présentées avec le composant de liste d’entité avec vue (nouvelle expérience qui remplace les traditionnelles grid).
La migration progressive de l’ensemble des grid de weavy en listes d’entités fait qu’on observe en standard l’arrivé de nouveaux rowaccess :
6.0 (Release 5 juin 2023)
Contacts de tiers (sw_data_customercontact)
Utilisateurs (sw_data_baseuser)
Historique de vente (sw_data_histoheader)
6.1 (Release 31 mai 2024)
Utilisateurs (sw_data_baseuser)
La rowaccess de la liste des utilisateurs a été retiré, car pour afficher l’annuaire des collaborateurs il ne faut pas avoir un filtrage des données.
Note : il est donc primordial de vider l’ensemble des rowaccess en base pour la table sw_data_baseuser (metatable_ID = 5).Files d’attente de tâches (sw_data_queue)
Affaires et opportunités (sw_data_deal)
Interventions (sw_data_intervention)
Améliorations
Parallélisation de l’exécution des requêtes listant les ID accessibles par l'utilisateur connecté.
L’ajout et la suppression étant dans l’unique table sw_sys_rowaccess, ces traitements ne sont pas parallélisables car il y a un lock de la table.Réécriture des requêtes et ajouts d’index pour optimiser l’exécution.
Algorithme d’optimisation de traitements
Supprimer tous les ID d’une table; puis insérer tous les ID d’une table
Faire le diff de modifications apportées; s’il est inférieur à 500 changements alors la modification est faite de manière plus fine