Bonjour @kosssi,
Ah, les subs OIDC… Une arlésienne chez nous 
.
Ça fait longtemps qu’on souhaite l’implémenter, chaque fois il y a de la douleur à faire sans.
Donc oui :
mais je viens de remarquer que si je change le mail d’un utilisateur, Grist crée un nouveau utilisateur 
C’est tout à fait vrai.
C’est un comportement que j’étais loin d’imaginer… j’ai un username qui lui ne change pas ou encore le sub qui est un id d’utilisateur mais faire le lien avec l’email je trouve ça pas terrible.
C’est douloureux mais c’est vrai
J’ai bien vu que l’on peut changer ça avec GRIST_OIDC_SP_PROFILE_EMAIL_ATTR
Je vois pas trop comment, c’est une variable d’environnement pour dire où trouver l’email dans la réponse de l’OIDC. Généralement on n’a pas trop à bidouiller dessus.
ou peut être que la fonctionnalité SCIM peut résoudre ceci.
Comment faites vous ?
Alors l’idéal, c’est de faire une modification en base de données et le faire avant qu’un·e utilisateur·rice se connecte avec son nouvel email.
FAIRE UNE SAUVEGARDE DE LA BASE AVANT CE QUI SUIT
Si le nouveau compte est créé mais qu’il est resté vide (pas invité à des espaces), il reste toujours possible de supprimer ce nouveau compte par SCIM (POST /api/scim/v2/Users/.search pour chercher l’ID du compte puis DELETE /api/scim/v2/Users/{userId} pour le supprimer, cf documentation) et faire l’opération en base ensuite.
L’opération en base consiste à lancer la requête SQL suivante :
UPDATE logins SET email='nouvel_email@example.com', display_email='nouvel_email@example.com' WHERE email='ancien_email@example.com';
Vous pouvez ensuite demander au nouvel utilisateur de se connecter, ça devrait être tout bon.
À noter qu’ensuite, il y a l’email à modifier à la main dans les permissions avancées des documents si l’appairage se fait par l’email.
je ping le spécialiste de la question