Maîtriser AppSheet : Stratégies de Role Management

Qu'est-ce que la gestion des rôles ? 

La Gestion des rôles, ou Role Management, permet aux créateurs d'applications de définir différents niveaux d'accès pour les utilisateurs en fonction de leurs rôles au sein de l'organisation ou de votre application. C’est l’une des plus grandes forces d’AppSheet car cela permet une gestion avec la plus fine granularité qu’il est possible d’avoir ! 

AppSheet permet une gestion sur les actions telles que l’ajout, la modification, la suppression ainsi que la lecture. Nous pouvons avoir un contrôle de ces actions sur les lignes d’une table et même sur les colonnes, et bien sûr mélanger le tout pour avoir une gestion pixel perfect. ⭐ 

Lorsque l’on travaille sur un Google Sheet partagé, votre seule option est de donner accès au Sheet en lecture voir en édition, néanmoins sur AppSheet nous pourrons, par exemple dans une application de facturation, mettre les règles suivantes :

• Un utilisateur ne peut pas voir les factures de tout le monde.
• Un utilisateur ne peut modifier que les factures qu’il a créées, sauf le champ validation et ne peut pas la supprimer.
• Le manager peut voir toutes les factures de son équipe, il ne peut modifier que le champ valider et peut supprimer les factures. 
• Seules certaines personnes peuvent voir les commentaires internes à une facture.

Voyons voir comment ce cas de figure peut être implémenté. Nous avons plusieurs manières de faire !

Définir les rôles dans votre app

• Si vous avez seulement besoin de deux rôles (Admin, User), AppSheet fournit une fonction appelée USERROLE() qui retourne le rôle de l'utilisateur (Admin ou User) en fonction des paramètres de l'application.

➡️Consultez la documentation ici qui détaille les meilleures pratiques : Documentation USERROLE()

• Si vous avez besoin de plus de deux rôles :
  • Vous pouvez avoir une table Users qui contient une colonne de type “Enum” avec votre rôle.
  • Vous pouvez baser votre application sur des Google Groups et attribuer un rôle à des groupes spécifiques.
  • Vous pouvez baser vos règles sur d'autres champs que les rôles, comme le Département ou l’Entité.

Deep dive dans “comment ca marche…” 

Dans cet article, nous aborderons deux exemples de Role Management :

• Un exemple où nous utilisons 2 rôles avec USERROLE() (Admin et User).
• Un exemple où nous utilisons 3 rôles (Admin, Manager, Member). 

1. Créer les rôles, soit dans une table d’utilisateur, soit affectant à des groupes (si nous utilisons des Google Group) 

Ici nous allons définir les règles pour la gestion des accès. Les règles sont appliquées à vos lignes et colonnes de données ou à vos actions sur les données (Delete, Create or Update).

Il existe plusieurs niveaux de gestion des accès : 

• Security filter 
• Table filter 
• Slice filter 
• Column filter 

2. Choisir le type de filtre

2.1 Security filter

C’est le niveau le plus haut de gestion des accès qui ne concerne que les lignes de données, PAS les colonnes ni les actions sur les données. Pour chaque ligne de la table, vous pouvez définir si l'utilisateur actuel peut y avoir accès ou non.

‍

‍Ici, par exemple, nous utilisons la gestion des deux rôles avec USERROLE() pour ne donner accès à la ligne que si vous êtes le propriétaire de la facture, le manager du propriétaire ou un administrateur.

Ainsi dans notre exemple, cela nous permettrait à ce qu'un utilisateur puisse ne voir que ses propres factures, tout en ayant l’administrateur ou le manager qui puisse également les voir.   

2.2 Table filter 

Le Table filter est au même niveau que le Security filter, mais il sert uniquement à définir les règles concernant les actions sur les données (par exemple, supprimer, créer ou mettre à jour).

En effet, nous voyons ci-dessus qu’au niveau de la table, une formule peut indiquer le niveau de granularité à appliquer sur chaque action.

Dans l'image ci-dessus, nous utilisons la fonction LOOKUP pour obtenir le rôle de l'utilisateur actuel.

• Si l'utilisateur actuel est un manager, il/elle peut seulement mettre à jour les données de la table.
• Si l'utilisateur actuel est un administrateur, il/elle peut exécuter n'importe quelle opération.
• Pour tous les autres utilisateurs (Membres dans notre exemple), ils peuvent seulement lire les données de la table.

2.3 Slice filter

Les filtres de Slice vous permettent de créer des règles qui s'appliquent à vos données (sur les lignes et colonnes) ainsi qu’à vos actions sur les données (supprimer, créer ou modifier). En termes de performance et de sécurité, il est préférable d'utiliser les filtres de sécurité et les filtres de table.

‍

Dans l’image ci-dessus: 

• “Row filter condition” permet de définir pour chaque ligne de la table si l'utilisateur actuel peut y avoir accès (comme pour le Security filter).
• “Slice Columns” permet de définir quelles colonnes doivent être présentes.
• “Slice Actions” permet de définir quelle(s) action(s) sont disponible pour ce slice, l’avantage d'utiliser un slice est que vous pouvez définir des règles différentes pour vos propres actions (par exemple "Composer un email") et pas seulement sur les actions de base sur les données. 

Nous pouvons regarder de plus près la condition présente dans le champs “Row filter condition”:

Cette condition nous permets de ne populer le Slice que si au moins une des trois conditions est vrai :

• L’utilisateur actuel fait parti de l’équipe grâce à la colonne [TEAM_MEMBERS]
• L’utilisateur actuel est manager de l’équipe via la colonne [MANAGER]
• L’utilisateur actuel est un administrateur via la colonne [RÔLE]

Cela nous permettrait donc d’afficher la ou les équipe(s) liées à un utilisateur, afin de par exemple faciliter la revue des factures, notamment dans le cas où une personne est manager de plusieurs équipes.

2.4 Columns filter 

Dans la table, vous pouvez définir pour chaque colonne, quelles colonnes doivent être affichées en fonction d'une formule. Vous pouvez utiliser cette fonctionnalité pour restreindre l'accès à certaines colonnes pour certains utilisateurs.

En regardant l'image ci-dessus, nous restreignons la vue de la colonne Internal Comments uniquement à certaines personnes. Si vous le souhaitez, vous pouvez également filtrer via une multitude de conditions différentes.

Regardons de plus près la formule : 

Cette formule nous permet de n'afficher la colonne contenant des commentaires internes, qui ne doit être visible qu’à un nombre restreint de personnes, nous allons donc vérifier si l’utilisateur connecté est soit le manager du propriétaire de la facture, ou bien un administrateur, ou finalement une personne des ressources humaines. Cela nous permet donc de restreindre la Lecture de certains champs.

Il est également possible de restreindre l’écriture à la colonne via la propriété Editable.

Ainsi, comme nous l’avons vu dans notre exemple, seul le manager peut modifier le champs Validation pour une facture, à condition que la facture soit émise par un membre de son équipe.

Nous pouvons vérifier cela  grâce à la formule dans le champ Editable, comme montré ci-dessus. Cela nous permet donc de restreindre l’Écriture de certains champs.

Par ailleurs, si vous souhaitez utiliser la vue en onglets via une colonne de type Show, gardez toujours à l'esprit que les colonnes peuvent apparaître même si elles sont vides.

Conclusion

En conclusion, nous avons plusieurs niveaux de filtres au sein d’une application AppSheet, chacune ayant des avantages et conséquences différentes pour votre application. Attention toutefois à toujours utiliser les bons filtres, car s’ils sont mal utilisés, votre application risquera très rapidement de devenir difficile à maintenir, ou bien d’avoir des problèmes de performance.

💬N'hésitez pas à nous contacter chez Idun Group pour explorer ensemble vos cas d’utilisation ou organiser une démonstration live !