Merci @david. Assez drôle, c’est exactement ce que j’ai fait pour faire le lien dans l’autre sens (depuis les profils utilisateur de mon application Rails vers les profils utilisateur Discourse) via ce plugin Discourse (/user-by-id/123/summary) puisque mon application Rails stocke l’ID utilisateur Discourse au lieu du nom d’utilisateur (car les noms d’utilisateur peuvent changer).
Cette solution fonctionnerait dans l’autre sens, sauf que tous les utilisateurs du forum n’ont pas de profils utilisateur dans mon application Rails. Un utilisateur Rails n’est créé qu’une fois que l’utilisateur Discourse ‘rejoint’ l’organisation, alors que le forum Discourse peut contenir des non-membres.
Je suppose donc que mes deux options sont :
A) Créer un plugin JavaScript qui envoie une requête ajax à mon application Rails pour déterminer si l’utilisateur Discourse est également un utilisateur de l’application Rails, et si oui, afficher un lien ; ou
B) Au moment où l’utilisateur Rails est créé et lié à l’utilisateur Discourse, en plus de stocker l’ID utilisateur Discourse dans la base de données de l’application Rails, stocker d’une manière ou d’une autre l’ID utilisateur Rails dans le profil utilisateur Discourse (par exemple, comme champ utilisateur personnalisé).
Je pense que (B) est la meilleure solution (à condition que le champ utilisateur personnalisé ne soit pas modifiable sauf par les administrateurs), bien que je ne sois pas familier avec les champs personnalisés ni avec leur accessibilité via l’API.
EDIT : Je me souviens maintenant de la dernière fois que j’ai examiné cela : le problème est que les champs utilisateur personnalisés sont modifiables par l’utilisateur, ce qui en fait un mauvais endroit pour stocker une référence générée par le système comme celle-ci 