Mise à jour de propriétés d'utilisateur personnalisées via API

Bonjour,

j’utilise une notion de “domaines” pour restreindre les accès aux données de Grist.

Pour cela, j’ai fait les manips suivantes :

  • via le menu des permissions avancées, une propriété d’utilisateur personnalisée “domaines” a été ajoutée pour renseigner les “domaines” autorisés pour chaque utilisateur.
  • chaque table de mon document Grist contient une colonne indiquant son “domaine” d’appartenance.
  • via le menu des permissions avancées, des règles d’accès sur chaque table du document ont été activées pour n’afficher à un utilisateur que les lignes dont le domaine appartient à la liste de ses domaines autorisés.

Cette solution a le premier mérite de fonctionner et c’est déjà bien !

Pour autant, cela implique pour le moment une gestion manuelle de la propriété utilisateur personnalisée “domaines”. Ex :

  • si un utilisateur “n’appartient” plus à un domaine, il faut pouvoir lui retirer ce domaine de sa liste.
  • quand un nouvel utilisateur arrive il faut lui déclarer les domaines auxquels il a le droit d’accéder.

Cette gestion des utilisateurs et de leurs domaines étant actuellement réalisée dans un outil tiers, je me demande s’il ne serait pas possible de coupler cet outil tiers à Grist via l’API de Grist, afin que les utilisateurs et leurs domaines soient automatiquement mis à jour dans Grist ?

J’ai parcouru (trop ?) rapidement la console d’api associée à mon document mais hormis la partie SCIM qui pourrait peut-être faire l’affaire, je ne crois pas avoir vu passer d’opération en ce sens.

Avant de creuser plus avant la piste SCIM, quelqu’un connaitrait il une opération via l’API permettant de modifier des propriétés personnalisées d’un utilisateur ?

Je suis aussi preneur d’autres pistes ou d’amélioration si la solution que j’envisage actuellement n’est pas la plus adaptée.

Merci par avance.

Bonjour,

Je pars du principe que vous avez une table d’utilisateurs dans votre document dans laquelle vous stockez leur mail et leur domaine. Vous utilisez ensuite cette table comme “table d’appairage” dans les permissions.

Pour la màj vous pouvez regarder du côté de l’appel

PATCH /docs/{docId}/tables/{tableId}/records

Qui permet de modifier un enregistrement dans la table (le domaine d’un utilisateur dans votre cas).

Pour faire les requêtes et le lien entre les deux outils, vous pouvez passer par un outil d’automatisation comme n8n

Merci @audezu c’est effectivement cela.

Ce n’est pas ma lecture (trop) rapide de l’API qui est en cause mais plutôt le “raccourci” dans ma tête qui m’a fait zapper que les propriétés utilisateurs personnalisées étaient issues d’une table “utilisateurs” complètement classique et à ce titre accessible via l’API comme toutes les autres données de tables.

Merci pour le rappel de cette “évidence” qui m’avait complètement échappé !

1 « J'aime »