Contexte
Se saborder volontairement en tant que propriétaire n’étant pas très intuitif, une petite explication pour commencer.
Par construction, Grist donne de grands pouvoirs d’administration aux propriétaires des tableaux, tout en faisant de chaque utilisateur qui crée/héberge un tableau son propriétaire, donc un administrateur de facto.
Mais au quotidien, les propriétaires sont avant tout des éditeurs parmi les autres : il font les mêmes manipulations, ils collent par erreur dans la case d’à côté (celle qui contenait une formule), ils déplacent accidentellement une vue, ils désactivent temporairement un filtre mais enregistrent son état par réflexe… Et leurs modifications s’appliquent instantanément à tous les autres utilisateurs.
Objectif
Vu qu’on ne peut pas dissocier les identités de l’utilisateur connecté en en un compte qui opèrerait la majorité du temps en éditeur et un autre en capacité de toucher à la structure du tableau, on va utiliser un indicateur qui empêchera les utilisateurs disposant du rôle OWNER d’apporter des modifications à la structure quand ça n’est pas absolument nécessaire.
Dans l’idéal, il faudrait :
- Qu’il soit activable compte par compte. De sorte à ne pas propulser instantanément tous les OWNER en admin mode quand juste l’un d’entre eux en a besoin.
- Que la règle utilisée soit dans les permissions avancées soit structurée de sorte à ne pas perdre le contrôle d’un tableau.
- Que cet indicateur soit volatile, par exemple : se désactive automatiquement passé X heures/1jour, réinitialisé à la sortie de la session, etc. Ou à défaut qu’il y ait une indication visuelle pour rappeler au propriétaire que le mode ADMIN est actif avec son profil.
Etape 1 - Préparer la table Utilisateurs
On commence par ajouter les propriétaires du tableau à la liste des utilisateurs. Ici la seule information importante à saisir est l’adresse mail de chaque propriétaire.
On crée une colonne “Mode limité”, formule d’initialisation =True pour que cette case soit active par défaut sur les nouvelles lignes.
On verra à l’étape 3 pourquoi le bouton est défini comme ça et pas dans le sens inverse.
Pour enfoncer visuellement le clou, on peut ajouter une mise en forme conditionnelle pour la colonne quand le bouton est désactivé :
Etape 2 - Créer un repère visuel pour le mode ADMIN
Malheureusement, je n’ai pas trouvé de méthode fonctionnelle qui permettrait d’imposer un “timeout” par formule[1] pour éteindre automatiquement le mode ADMIN passé un certain temps ou à la session suivante (voir le P.S. à la fin du post).
Pour au moins rendre la chose visible, on va utiliser une table “Mode ADMIN”, 1 seule colonne “Message”, 1 seule ligne contenant un texte explicatif quelconque, voire du HTML pour attirer l’attention.
Elle sera à afficher dans une nouvelle page “
Mode ADMIN”, placée en 1ère position dans la liste des pages, de sorte à être chargée en 1er à l’ouverture du tableau.
Dans cette page, on va avoir besoin de 2 vues :
- Une vue de type Fiche pointant sur la table Utilisateurs, Filtre : Mode limité = True
- Une vue personnalisée pointant vers la table Mode ADMIN, widget “Bloc-notes”, ou “Visionneuse HTML” selon la mise en forme choisie
Etape 3 - Mettre en place les permissions avancées
Faites une copie/un export de votre tableau avant de commencer à modifier les droits
On va avoir besoin d’un set de plusieurs règles pour les tables “Utilisateur”, “Mode ADMIN” ainsi que pour gérer les autorisation de modification sur la structure du tableau.
-
[Prérequis] Si vous ne l’avez pas déjà défini, il va falloir ajouter au tableau des propriétés d’utilisateur :
Dans l’exemple, l’utilisateur connecté sera lié par son mail au contenu des autres colonnes de la table Utilisateurs. Ça permettra à Grist d’aller récupérer l’état du Mode limité pour l’utilisateur courant viauser.Profil.Mode_limite -
Table Utilisateurs :
Ces 2 règles vont masquer le contenu de la colonne Mode limité pour tout le monde. Quant aux propriétaires, ils verront que la colonne existe mais ne pourront voir et agir que sur le Mode limité de leur propre compte (i.e. seulement la ligne ou l’adresse mail correspond à la leur).
En variante, on pourrait autoriser la lecture seule aux propriétaires. -
Table Mode ADMIN :
Ces 2 règles servent à escamoter la table (et donc la page) du mode ADMIN pour tout le monde. Seuls les propriétaires dont le mode limité a été désactivé la verront.
A ce stade, on a ce qu’il faut pour un 1er test de la logique. Si la formule est comprise, vous devriez :- Voir et pouvoir manipuler uniquement le switch Mode limité correspondant à votre ligne dans la table Utilisateurs.
- Voir la page Mode ADMIN ou pas en fonction de l’état de votre switch.
-
Règles spéciales :
On en arrive à la partie délicate. Si vous ne l’avez pas encore fait, c’est le moment pour créer une copie ou exporter votre tableau.La 1ère règle
user.Access == OWNER and not user.Profil.Mode_limiteva maintenir les droits admin pour les propriétaires si leur Mode limité est désactivé.La 2nde règle
user.Access != OWNER or (user.Access == OWNER and user.Profil.Mode_limite)va couper l’accès à la structure du tableau pour tous les autres cas (tous utilisateurs non propriétaires + propriétaires dont le Mode limité est actif).
Elle est accompagnée d’un message de blocage personnaliséSeuls les propriétaires du tableau ET n’étant pas en mode limité peuvent apporter des modifications à la structure du tableau.
“Mode limité” VS “Mode ADMIN”
Il s’agit d’un garde-fou pour que la coupure d’accès à la structure soit une étape explicite.
Si on définit que “actif = mode ADMIN” (donc blocage implicite pour touts les autres cas), alors un propriétaire dont Grist ne parviendrait pas à déterminer l’état du mode ADMIN n’aurait aucun accès à la structure du tableau.
En utilisant la condition inverse “désactivé = mode ADMIN”, l’admin n’est rejetée que si le Mode limité est explicitement coupé pour le propriétaire, donc le rejet ne s’applique pas si la valeur n’est pas définie pour le mode limité (parce que le propriétaire n’est pas dans la liste des utilisateurs, parce qu’on a supprimé par inadvertance les valeurs dans la colonne Mode limité, etc.).
Résultat
Avec ces réglages, vous devriez obtenir un comportement de ce type :
Pour inclure une logique un timeout, il faudrait pouvoir comparer l’état au déclenchement (facile à faire avec les formules d’initialisation) avec l’état actuel. Or, contrairement aux formules d’initialisation, les formules classiques :
- N’ont pas accès aux données de l’utilisateur courant (ex. : user.sessionID)
- Ont bien accès à certaines valeurs volatiles comme la date et heure courante, mais ne les recalculent pas en permanence pour des raisons de performance.
J’en déduis que Grist ne recalcule une formule que si un changement survient dans une des cellules participant au calcul, ou de temps à autres lorsqu’il recharge son moteur.