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.

sw_sys_rowaccessstatus

Liste les demandes de calculs de droits d’accès

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

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

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.

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 accéder au 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.
Note : ne pas oublier de vider le rowacess pour la table après avoir désactivé.

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