Est-il acceptable de mettre à jour external_id sur la base de données discourse ?

[Nicolas_Barrera]

J’ai parcouru le forum à la recherche d’informations sur la mise à jour de external_id dans la base de données Discourse.

J’ai trouvé ce sujet intéressant :

Is it possible to change users SSO's external_id after a DB migration?

First I had issues with the external_id field on SSO, because they were all initially strings of length 16, and later I stored 24chars strings, but it completely messed up, you could get logged under a different user, it seems it cropped the external_id length, but that was hard to debug. So I make sure to keep external_id with the same length, it’s not really practical, why not using a TEXT column type for it? And my question is also, can I update the external_id of existing users, after doin…

Cependant, j’aimerais avoir quelques éclaircissements sur les implications de la mise à jour de external_id dans la base de données.

Puis-je simplement exécuter une mise à jour SQL et définir le nouvel external_id correct ? Cela pourrait-il entraîner des problèmes cachés ? Par exemple, si l’utilisateur a une session ouverte ou autre chose ?

J’ai créé les utilisateurs via SSO en utilisant un external_id qui est l’ID du compte de l’utilisateur dans le système externe. (Je devrai peut-être modéliser autre chose, mais ce serait bien de pouvoir éviter de changer le modèle du système externe, du moins pour l’instant)

Le problème pour moi est que la personne peut avoir plus d’un compte dans le système externe et peut fusionner ces comptes en un seul, donc parfois, en fonction de la façon dont il fusionne, un nouvel external_id peut apparaître pour le même utilisateur/email.

J’utilise l’option require_activation, donc comme je l’ai lu dans le sujet mentionné, je ne peux pas supprimer l’enregistrement et attendre qu’il soit recréé.

Merci

[RGJ (Richard - Communiteq)]

@Nicolas_Barrera

puis-je simplement émettre une mise à jour sql et définir le nouvel external_id correct ?

Oui, vous devriez pouvoir le faire, mais vous devriez d’abord résoudre le vrai problème

@Nicolas_Barrera

le problème pour moi est que la personne peut avoir plus d’un compte sur le système externe et peut fusionner ces comptes en un seul, donc parfois, en fonction de la façon dont il fusionne, un nouvel external_id peut provenir du même utilisateur/email.

par exemple, lorsque les comptes sont fusionnés, assurez-vous toujours que l’ID le plus bas est attribué / utilisé.

[Nicolas_Barrera]

Oui.. lors des fusions de comptes externes, je respecte le compte le plus ancien… mais parfois ce n’est pas ce dont j’ai besoin.

certains comptes interagissent avec le forum (type A, disons) et certains autres comptes ne sont pas destinés à cela (type B).

donc s’ils créent d’abord un compte de type B…
et plus tard, ils créent un compte de type A, ils font du SSO avec celui-ci sur le forum

et plus tard, ils fusionnent A et B et honorent le compte le plus ancien qui a un external_id différent

donc oui…
J’ai besoin de trouver une solution pour mon truc de système externe…

mais je pense que je vais mettre en place une tâche cron quotidienne qui vérifie si l’une de ces choses s’est produite et corrige les external_ids pour le moment.

Merci !

[RGJ (Richard - Communiteq)]

Dans ce cas, vous pourriez soit :

a) synchroniser tous les comptes avec Discourse en utilisant le mécanisme de synchronisation SSO
b) garder une trace des comptes qui ont été utilisés pour se connecter à Discourse
ou
c) lors de la fusion, effectuer une recherche d’ID externe pour déterminer quel(s) compte(s) ont été utilisé(s) avec Discourse

[system (system) A fermé ce sujet ()]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.