Les utilisateurs ont tous les droits sur la table enseignants_formations pour leurs enregistrements filtrés sur leur e-mail.
Ils ne peuvent que lire la table Enseignants (Table1) filtré sur leur e-mail.
Ils ne peuvent que lire la table Formations.
Si je bascule sur un compte utilisateur avec ‘Voir en tant que’, dans la table Enseignants_formations, je ne vois bien que le l’ID utilisateur dans la liste déroulante.
Pour essayer de t’aider, plusieurs éléments interrogent :
Dans la déclaration de tes ACL (permissions avancées), tu as défini deux propriétés (filterEmailInscription et filterEmailEnseignant) qui proviennent de deux tables différents… ce n’est pas pas forcément bloquant mais généralement on utilise des tables différentes lorsqu’on souhaite gérer des populations différentes, et justement dans des tables différentes. Cette stratégie est intéressante losque la diffusion sélective d’informations que l’on souhaite définir ne repose pas sur les même critères.
Exemple de gestion de 4 profils utilisateurs dans des tables indépendantes.
Or j’ai la sensation que tu n’as qu’une population à gérer.
Je te conseillerais d’avoir une table unique (SYSTEM_AUTORIZATIONS) avec les colonnes
EMAIL | NOM | PRENOM | PROFIL | (et les colonnes que tu as besoin pour définir son périmètre) que tu ajoutes en tant que « Propréités utilisateurs » dans les ACL=permissions avancées.
Et pour le problème de visibilité, les règles décrites ne permettent pas à un enseignant de voir les lignes de la table formation (user.Access in [EDITOR] => indique que la règle ne s’applique que pour les utilsiateurs avec le droit Editeur)… or si j’ai bien « deviné » tes jointures de table, la colonne IDForm provient de cette table. Il est donc nécessaire que l’enseignant puisse voir également les lignes de la table jointe (= FORMATIONS).
Je t’invite à lire avec attention l’excellent guide de @ailepet ici
N’ayant pas accès à toute vos tables… c’est un peu délicat pour comprendre votre besoin, mais j’imagine que vous voulez un contrôle d’accès granulaire pour un unique profil utilisateur.
Présentation du cas d’étude
L’objectif est de restreindre l’accès aux données pour un profil unique :
Enseignant : Un enseignant peut être affecté sur une ou plusieurs écoles.
Règle ACL : Les enseignants n’auront accès qu’en lecture seule aux lignes des tables de données qui correspondent aux codes des écoles de leur périmètre.
Définition de la table utilisateur SYSTEM_AUTORIZATION_DEC
Pour associer chaque utilisateur à ses écoles, on crée une table dédiée SYSTEM_AUTORIZATION_DEC. La colonne PERIMETRE_ECOLES permet de savoir le périmètre de responsabilité de l’enseignant, et sera utilisé pour l’écriture des règles granulaires (ACL).
Dans la vue des permissions avancées, on ajoute alors les propriétés utilisateurs de Grist (ACL), avec l’appairage suivant :
NAME
PROPRIETE D’APPAIRAGE
TABLE D’APPAIRAGE
COLONNE_CIBLE
Team_DEC
user.Email
SYSTEM_AUTORIZATION_DEC
EMAIL
Définition d’une règle ACL pour l’accès à une table
Il reste alors à définir la politique de diffusion sélective dans les tables de données. Imaginons que vous avez la tables ‹ DATA_ECOLES › suivante
CODE_ECOLE
NOM_ECOLE
COMMUNE
TYPE_ETABLISSEMENT
NB_ELEVES
codeEcole1
École Maternelle Les Tilleuls
Orléans
Maternelle
145
codeEcole2
École Élémentaire Jean Jaurès
Fleury-les-Aubrais
Élémentaire
230
codeEcole3
École Primaire Victor Hugo
Olivet
Primaire
185
codeEcole4
École Maternelle Les Marronniers
Saint-Jean-de-Braye
Maternelle
112
codeEcole5
École Élémentaire Jules Ferry
Saran
Élémentaire
204
Pour que les directeurs d’écoles ne voient que leur périmètre (les écoles qui lui sont affectées), on utlisera la règle ACL suivante sur la table DATA_ECOLES :
Règle
Droits
Explication
user.Access in [OWNER]
RUCD
Accès administrateur par défaut pour les propriétaires du document
user.Team_DEC.PROFIL == 'DEC' and rec.CODE_ECOLE in user.Team_DEC.PERIMETRE_ECOLES
Rxxx
Accès en lecture seule des lignes du périmètre (une ou plusieurs écoles) d’un utilisateur avec le profil directeur d’école.
Tous les autres
xxxx
On bloque l’accès dans tous les autres cas (stratégie deny by default)
Remarques
La stratégie deny by default fonctionne par liste blanche (whitelisting). L’accès est strictement interdit par défaut, et seules les exceptions explicitement listées viennent l’autoriser.
Pour que l’opérateur in fonctionne correctement avec une liste de codes multiples dans le cas d’affectation multiple (ex: codeEcole2, codeEcole3), la colonne PERIMETRE_ECOLES de la table d’autorisation doit être stockée sous forme de chaîne de caractères (i.e. ToString d’une collection d’item = serialisation string = transformation en chaîne de caractères).
Si vous avez déporter la définition de vos écoles dans une autre table (ECOLES) avec une référence multiple dans la table SYSTEM_AUTORIZATION_DEC, vous devez alors transformer cette colonne ref mutiple en chaine de caractères dans une nouvelle colonne de SYSTEM_AUTORIZATION_DEC pour pouvoir l’utiliser dans vos règles ACL avec l’opérateur in. Pour ce faire, utiliser une formule Grist Python avec la fonction repr() pour passer d’une colonne de références multiples à sa représentation string. Par exemple :
codes = [ecole.CODE for ecole in $ECOLES_AFFECTEES] if $ECOLES_AFFECTEES else []
return repr(codes)
Ca sera peut être plus parlant avec une capture d’écran (c’est un cas avec 4 profils utilisateurs, focaliser vous sur un seul profil).
Dans cette définition de permissions avancées, la table DEC est :
Accessible avec tous les droits pour les propriétaires de l’espace
Accessible en lecture seule (Rxxx) aux utilisateurs avec le profil « DEC », et ces derniers ne peuvent voir que les lignes qui correspondent à leur écoles.
Accessible en lecture seule aux utilisateurs avec le profil « ERUN ». Le perimètre des ERUN est différent, il est calculé par l’affectation de l’ERUN à une ou plusieurs circonscriptions duquel on en déduit le perimètre des écoles rattachés aux circos… mais c’est une autre histoire plus complexe.
Vous utilisez une règle par négation. C’est tout à fait possible, mais je vous conseille plutôt de mettre en place une stratégie « Whiteliste = liste blanche » en ajoutant un premier deny for all puis en ajoutant successivement les autorisations
Vous avez nommez votre population filtreEmail dans vos propriétés utilisateurs, ca manque de sémantique. Renommer en TeamEnseignant par exemple. Ca change rien du point de vue du code, mais c’est plus simple à lire/comprendre.
Attention à l’emploi de règles ACL disjointes, je vous déconseille cette écriture.
user.Email == user.TeamENS.email avec RUCD
user.Email != user.TeamENS.email avec xxxx
Je suis surpris par l’emploi du champ newRec. Etes vous sur de son emploi ? newRec s’utilise lorsqu’un utilisateur propose de changer un enregistrement, de plus êtes vous sur que jaugePleine est un booléen, toujours pour plus de sémantique on s’attendrait à un test écrit places_disponibles == false/true. De plus vous n’avez pas préciser les règles pour R, C et D dans ce cas (grisés).
Renommer votre colonne eMail en majuscule (ou miniscule). Eviter le mélange, les caractéres spéciaux, les espaces. Et garder la meme stratégie pour toutes vos colonnes.
Peut être essayer cette configuration
Règle
Droits
Explication
user.Access in [OWNER]
RUCD
Accès admin de plein droit pour les propriétaires du document.
rec.EMAIL== user.TeamENS.EMAIL
RUCD
Accès en lecture et écriture aux lignes de leur périmètre pour les enseignants (Etes vous sur qu’il puisse créer de nouvelles lignes ? de supprimer des lignes existantes ?)
Tous les autres
xxxx
Bloque l’accès (stratégie deny by default)
Pour la table Formations
Vous avez mis
user.Access in [OWNER] avec RUCD
user.Access in [EDITOR] avec Rxxx
Tous les propriétaires ont donc un accès admin
Tous les édtieurs (si vos utilisateurs sont éditeurs) ont un accès à toutes les lignes en lecture seule.
Pour la table Enseignants
Même remarques
Règle
Droits
Explication
user.Access in [OWNER]
RUCD
Accès admin de plein droit pour les propriétaires du document.
Quand je crée un nouvel enregistrement, la liste déroulante sous EMAIL ne montre bien que le mail de l’utilisateur, j’imagine que c’est le filtre fait sur Enseignants qui provoque ça.
Merci de votre aide.
Fabien Beauchamp
P.S.:
J’ai gardé mes dénominations pour aller vite mais je comprends bien vos remarques.
newRec.jaugePleine marche, ne m’en demandez pas plus, je vais le garder comme ça.
La seule différence que je vois maintenant entre votre document et le mien est que dans ma table Inscriptions, l’e-mail est un champ référence lié au champ EMAIL de la table Enseignants.
Dans votre cas, c’est un champ de données sans référence.
J’avais trouvé une solution un peu plus sale en créant un identifiant numérique dans ma table enseignants, en reportant cet identifiant comme données descendue dans inscriptions et en filtrant sur ce champ.
.
