Gestion des permissions avancées : reférence vs titre

je cherche à définir des Row-level access.
J’ai une table Session d’écoute qui permet de lister les différentes immersions.

J’ai une table Observation qui permet de lister les observation, Dans cette table une colonne Session type référence qui me permet de renseigner à quelle Session d’écoute correspond l’observation.

J’ai une table Team qui me permet de manager mes permissions avancées. Il y a dedans les emails des users et ils ont une colonne Session également de type référence qui pointe vers ma table Session d’écoute.

En pièce jointe les règles déterminées dans mes permissions

la table Team

le restultat sur ma table observation :

Si je change le type de mes colonnes dans mes tables Team et Observation, alors le row-level access fonctionne correctement :

Je voudrais pouvoir appliquer cette règle en gardant mes colonnes en type « Référence » et je pense mal faire quelque chose dans la syntaxe de la règle que je cherche à appliquer

MMMH.
pour une raison que j’ignore ça fonctionne

Problème réglé ?

A première vue, si les colonnes Session_associee (table Observations) et session (table Team) sont de type Référence, alors == et in devraient fonctionner. Sachant que == teste l’égalité stricte alors que in teste l’inclusion (utile si session dans la table team est de type Référence multiple).

Là où ça se complique c’est si l’une des deux variables à comparer n’est pas de type référence…

Pas totalement réglé. Pour mes observations c’est bon. J’ai mes utilisateurs qui selon leur session ne voient que les observations qui concernent leur session.

maintenant j’ai une table insight. Les observations pointent vers les lignes insights (un insight peut être rattaché à plusieurs observations) et j’ai une colonne de session associée pour savoir de quelles sessions proviennent ces observations. Voici ma formule dans ma colonne session_associee.insight (elle s’appelle Irritants_360)

Dans Irritants_360, colonne Session_associee

Récupère toutes les observations qui référencent cet irritant

observations = Observations_360.lookupRecords(Irritants_S2A=CONTAINS($id))

Collecte les sessions uniques de ces observations

sessions = set()
for obs in observations:
if obs.Session_associee:
sessions.add(obs.Session_associee.id)

Retourne la liste des IDs de sessions

list(sessions)

ma colonne session_associe de ma table insight est en format « reference multiple »

Ce que je voudrais c’est que mon utilisateur de la session Rouen ne voit que la ligne d’insight de Rouen, et pas les lignes d’insight où Rouen n’est pas rattaché comme session associée.
En gros j’ai ça :

et je voudrais ça (que je simule pour l’image avec un filtre)

voici ce que j’ai mis dans les permissions de la table Irritants_360 (j’ai imité ce qui a été fait pour la table Observations_360) :

mais mon resultat final est celui-ci :
Capture d'écran 2026-01-19 172033

Au lieu de user.Team.session == rec.Session_associee, essayez :

  • rec.Session_associee in user.Team.session
  • ou user.Team.session in rec.Session_associee

Comme je l’ai indiqué, ça devrait normalement marcher avec la syntaxe in (qui teste si une référence apparaît dans une liste de références) même si je ne suis pas sûr de l’ordre exact.

J’ai déjà été confronté à une égalité qui ne fonctionne pas avec des références, une autre technique à essayer est de comparer directement les identifiants des références (par exemple, 2 pour « Cafe » si « Cafe » est le deuxième utilisateur dans la table) au lieu de comparer les références en elles-mêmes.

Je propose donc la formule $Session_associee.id == user.Team.session, ou alors $Session_associee.id == user.Team.session.id

Si une de ces formules fonctionne, je ferais remonter le problème sur la base de code de Grist.

ça a fonctionné avec le screen suivant :

bizarrement si je mets les mêmes conditions pour la table observation ça ne fonctionne pas (et franchement je ne comprends pas bien pourquoi, étant donné que je cherche à vérifier la même valeur en référence)

donc j’ai ça en observation et ça fonctionne :

Donc je vous remercie beaucoup !

j"ia une toute dernière question et ensuite on pourra clore le sujet. J’ai des lignes qui sont colorés selon le statut de l’irritant. Lorsque je regarde en tant qu’owner, les couleurs d’appliquent correctement. Mais pas si je prends un profil « Lecture seule »

Screen avec les conditions d’aspect de ligne qui fonctionne (Owner) :

Screen ave les conditions d’aspect de ligne qui ne fonctionne pas (Viewer) :

Bravo pour les permissions !

Concernant les styles conditionnels, je subodore que les utilisateurs ayant les droits Viewer n’ont pas de droit sur les colonnes qui sont utilisées dans la formule. De ce fait, s’ils ne sont pas censés voir cette information, ils ne sont pas non plus censés voir une couleur basée sur cette information (car ça revient un peu au même)…

Merci pour votre aide!

Comme la couleur dépend de la valeur dans la colonne « statut » et qu’ils ont la permission de voir cette colonne, il ne devrait normalement pas y avoir de problème sur l’application des styles conditionnels.
Est ce que c’est possible que comme la couleur s’applique sur l’ensemble de la ligne, et qu’ils ne peuvent avoir accès à toutes les colonnes alors ça bug ?

C’est cette ligne qui bloque
Capture d'écran 2026-01-20 141935

Si c’est réglable c’est top. C’est pas vital mais les couleurs sont facilitatrice pour la lisibilité du statut. Tout le concept c’est que je veux mettre à disposition des données pour des gens qui sont pas habitués à ce rendre sur Grist, donc d’avoir quelque chose où ils saisissent en un coup d’oeil l’information qu’ils cherchent et le codes couleurs peuvent en faire partie.

Comme la couleur dépend de la valeur dans la colonne « statut » et qu’ils ont la permission de voir cette colonne, il ne devrait normalement pas y avoir de problème sur l’application des styles conditionnels.

Attention, ce n’est pas tout à fait exact : $Statut est de type Référence et la formule appelle son attribut $Statut_irritant.

Est-ce que vos viewers ont les droits de consultation sur la table qui contient $Statut, et en particulier sur la colonne $Statut_irritant ?

Vous avez raison, les statuts sont définis dans une table « nomenclature » dans la colonne « statut_irritant »
class Table_nomenclature:
Statut_irritant = grist.Text()

ils n’ont pas accès à cette table. J’ai donc cherché à modifier la permission en mettant sur ma Table_nomenclature la condition suivante :

ce qui fait apparaitre la table nomenclature à gauche pour un viewer :


et il ne voit que la colonne statut_irritant de cette table.

mais la couleur ne s’applique pas.

Je viens d’essayer également en supprimant totalement la table nomenclature de mes permissions avancées. Je vois donc toute la table nomenclature en tant que VIEWER mais pas de couleur sur les lignes…

Au passage la condition d’application des couleurs dans la vue de colonne ne montre pas la règle « Si »

Je comprends pas pourquoi ça marche avec les couleurs de mes « choix unique » qui sont aussi dans ma table de nomenclature mais pas pour la couleur des lignes.

Si je retire toutes les restrictions sur cette conditions, mes viewers voient tous les irritants (même ceux qui les concernent pas, mais les couleurs s’appliquent…?)

J’ai également essayé en passant ma colonne statut de ma table irritants_360 en type texte en adaptant le « If » de l’aspect de la ligne. Depuis le point de vue OWNER la couleur s’applique correctement mais toujours pas côté VIEWER.
Visiblement il n’y a pas seulement le fait qu’il s’agisse d’une référence vers ma table nomenclature qui bloque l’aspect de la ligne…

J’ai à nouveau un probleme. (en plus j’ai effacé par erreur le message précédent).

Mon utilisateur cafe devrait voir une ligne dans la table irritant 360 mais il ne voit rien, alors qu’il voit les lignes correspondantes dans la table observations 360…

Table irritants 360 :

permissions avancées irritants 360 :

tables observations 360 :

permissions avancées observations 360 :

Je ne comprends pas pourquoi ça ne fonctionne plus. Plus haut dans la conversation ça fonctionnait, j’ai essayé de changé la syntaxe dans tous les sens mais rien n’y fait…

help please

C’est normal que vous ayez
user.Team.session in rec.Session_associee dans irritants 360
et le contraire dans observations 360 ?

Je ne sais pas si c’est normal, j’avais suivi les conseils des précédents échanges dans le thread et ça avait fonctionné comme ça.
hier j’ai essayé de mettre exactement les mêmes règles que dans observations 360 sur ma table irritants 360 mais ça ne changeait rien.

J’essaierais de mettre la même condition sur la colonne Irritant_S2A_

rec.Session_associee in user.Team.session
ou
user.Team.session in rec.Session_associee

ça fonctionne si je fais rec.Session_associee in user.Team.session et si ma colonne est de type « Référence ».
Or j’ai besoin qu’elle soit de type « Référence multiple » et là ça ne fonctionne plus.