Ce pas-à-pas est déjà très complet et représentatif du cas ultra-courant utilisateurs / profils / sets de droits. J’ai également apprécié ce Docs qui éclaire notamment sur l’ordre de priorité des règles, les objets spéciaux… : Docs
Une fois que les règles sont en place et que j’ai pu simuler leur effet en affichant le tableau “en tant que”, pour valider que chaque profil se comporte comme attendu, il me reste (au moins) 2 question avant ouverture :
Vu que ma table des utilisateurs est déjà définie dans le tableau, est-ce suffisant pour le leur rendre accessible ou faut-il également doubler par la déclaration de ces même utilisateurs dans les options de partage du tableau / ou à défaut activer l’accès public (lecteur ? éditeur ?) ?
Dans l’idéal, j’aurais préféré ne pas activer l’accès public (risque accrus d’exposition des données en cas de raté dans l’une des règles).
Dans le cas où certains des contributeurs du tableau sont également parmi les rôles propriétaires, a-t-on un moyen (sans leur couper définitivement l’herbe sous le pied en cas de besoin) de désactiver temporairement la modification accidentelle de la structure ?
Pour la seconde question, mon idée serait de moduler avec :
1 interrupteur “ADMIN mode” dans ma table Utilisateurs (avec quelques formules d’init. pour limiter son activation à des personnes et pour une plage de temps donnée)
Une règle dans cette section des permissions avancées :
Une formule interdisant la modif. de structure, du genre : user.Access == OWNER and not user.Profil.ADMIN_mode
Mais comment dire… J’ai un petit peu la main qui tremble avant de tenter tout ça !
Est-ce que quelqu’un a déjà tenté ça et si oui, a-t-il eu des regrets ?
Je n’ai pas très bien compris ton interrogation… mais je pense qu’il y a une confusion entre :
la définition des droits des utilisateurs accessible dans « Partager > Gérer les utilsiateurs ». Pour qu’un utilisateur puisse accèder au document, il est nécessaire qu’il soit dans ajouter dans cette liste, et la on définit globalement son niveau de droits dans le document : OWNER, EDITOR ou VIEWER. Cette étape est obligatoire pour inviter un collaborateur à accéder au document.
la définition granulaire des règles ACL dans les permissions avancées, qui permet de mettre en place une diffusion sélective de l’information auprès des utilisateurs.
Remarque : dès lors que vous associez des propriétés utilisateurs à une table dans les permissions avancées et que vous l’alimentez, les utilisateurs n’ayant aucun accès au document apparaissent tout de même dans la liste « Voir en tant que », sous la section « AUTRES UTILISATEURS DE LA TABLE », avec le droit Éditeur. Autrement dit, ces utilisateurs n’ont pas d’accès direct au document Grist, mais une règle ACL leur est associée.
Dans l’exemple, ci-dessus, Jhon.Doe@ ne peut pas se connecter au document Grist (il n’a pas été invité), mais il apparait dans la table SYSTEM_AUTORIZATIONS utilisé pour définir les règles ACL.
Oui, il est possible d’écrire plusieurs règles pour chacune de vos populations. Raisonnez plutôt par profil utilisateur pour vous simplifier l’écriture des ces règles.
Si je comprends ce que vous écrivez vous voulez en plus du profil « super admin » identifié en tant que propriétaire du document, un autre profil admin.
Pour cela, j’ajouterais dans la table utilisé pour associé vos utlisateurs dans permissions avancées une colonne « PROFIL »
Règle
Droits
Explication
user.Access in [OWNER]
RUCD
Accès totale pour les propriétaires du document
user.Team.PROFIL == 'LECTEUR'
Rxxx
Lecture seule pour les utilisateurs avec le profil LECTEUR
user.Team.PROFIL == 'ADMIN'
RUCD
Accès totale pour les utilisateurs avec le profil ADMIN
sans oublier de bloquer l’accès pour tous les autres cas.
Ca ressemble à une anecdote que m’avait partagée @Raywan avec des propriétaires qui réduisent volontairement leurs droits admin grâce à un simple bouton bascule, pour limiter le risque qu’ils fassent des bêtises malgré eux… Donc je dirais que c’est faisable et plutôt une bonne idée !
Merci ! Ca répond à la question 1. Pour en tenter une synthèse :
Sas extérieur : les partages du tableau
Les utilisateurs dans cette liste obtiennent le droit d’atteindre le contenu du tableau (lecture ou édition ou propriétaire), ou alors on la laisse vide et on paramètre un accès public (lecture ou édition)
Sas intérieur : les permissions avancées
Les utilisateurs dans cette liste peuvent obtenir des droits différents (plus précis, plus élevés ou plus réduits qu’à l’étape précédente), mais uniquement si le sas extérieur les a laissé passer.
Pour leur permettre de traverser la première porte du sas et donc d’arriver à la seconde, on a donc le choix entre :
Soit réinscrire chaque utilisateur de notre table Utilisateurs dans les partages du tableau (donc double de gestion et risque de discordance)
Soit ouvrir en public le tableau (= toute personne connectée disposant du lien), en comptant sur le fait que la seconde porte est correctement conçue pour filtrer les accès.
Dans la seconde hypothèse, il me reste une interrogation : savez-vous si on peut se contenter d’un lien public en lecture seule, puis ensuite octroyer des droits plus élevés aux visiteurs répertoriés via les permissions avancées ? Ou faut-il que l’accès public soit lui aussi en édition pour que les droits d’écriture définis dans les permissions avancées s’appliquent ?
Pour la question 2, Manqué ! Mais Enro a répondu sur la faisabilité technique d’utiliser un switch on/off pour restreindre l’accès à la structure du tableau, y compris pour le rôle OWNER.
J’ai pu tester ça et ça fonctionne plutôt bien. Je prévois de faire un post là-dessus pour expliquer la méthode.
Tel que je le comprends, les droits Editeur ou Lecteur attribués en partageant le document en public déterminent les droits des utilisateurs anonymes (anon@getgrist.com). Si l’utilisateur qui clique sur le lien a un accès nominatif au document (en tant qu’utilisateur invité) alors ses droits nominatifs s’appliquent (le fait qu’ils prévalent ou non dépend comment les permissions avancées sont configurées).
?
Mais Enro a répondu sur la faisabilité technique d’utiliser un switch on/off pour restreindre l’accès à la structure du tableau, y compris pour le rôle OWNER.