Créer des utilisateurs staged via l'API ?

[mattdm (Matthew Miller)]

Je réfléchis à l’idée de créer un service de pont webhook+API pour connecter des catégories données sur deux forums Discourse différents. L’idée générale serait :

1. Un webhook sur chaque serveur pour les événements Topic et Post^[1]
2. Un écouteur qui prend ces événements et les réplique sur le serveur opposé via l’API
   • Euh, quelque chose pour éviter les boucles, évidemment^[2]
   • Vérifier si un utilisateur avec la même adresse e-mail existe sur le serveur opposé^[3]
   • Si aucun utilisateur de ce type n’existe, créer un utilisateur temporaire (staged user)
   • Modifier les paramètres de notification de l’utilisateur temporaire afin qu’il ne reçoive pas de notifications par e-mail^[4]
   • Créer ou mettre à jour le post sous l’utilisateur réel ou temporaire approprié
3. Probablement une routine planifiée pour parcourir les sujets et s’assurer que rien n’a été manqué, et éventuellement réordonner afin que les deux côtés soient d’accord

D’après Comprendre les statuts, rôles et permissions des utilisateurs, je pense que les utilisateurs temporaires feraient essentiellement ce que nous voulons – si quelqu’un créait un compte avec cette adresse e-mail plus tard, il pourrait le « réclamer » et interagir avec tous ses posts comme s’il avait toujours été là.

Mais, y a-t-il un moyen de créer un utilisateur temporaire via l’API ? Je ne vois pas cela dans Discourse API Docs.

---

1. et éventuellement aussi les événements Like et Solved, mais pas dans la première version ↩︎

2. J’y ai absolument pensé avant d’écrire cette liste ↩︎

3. en utilisant les adresses e-mail comme clé car les systèmes de compte peuvent ne pas avoir les mêmes noms d’utilisateur ↩︎

4. J’ai vu un post à ce sujet quelque part par ici… ↩︎

[Lilly (Lillian Louis)]

@mattdm

Mais, y a-t-il un moyen de créer un utilisateur mis en scène à partir de l’API ? Je ne vois rien dans la Documentation de l’API Discourse.

---

1. et éventuellement aussi les événements J’aime et Résolu, mais pas dans la première version ︎
2. J’ai définitivement pensé à cela avant de rédiger cette liste ︎
3. en utilisant les adresses e-mail comme clé car les systèmes de compte peuvent ne pas avoir les mêmes noms d’utilisateur ︎
4. J’ai vu un post à ce sujet quelque part par ici… ︎

Pas sûr si c’est ce que vous voulez ?

Creating a staged user with an API call

Yes, just create a user via the api. They won’t be “staged” at this point since they actually exist. If they ever need to log in, they can just reset their password. This is also possible Here is a rough example of how to create a user, active them, and generate an api key for them. def create_user user = { name: example1, email: "example1@example.com", password: "ZvAmmkcSWQfsPQLBksg7wK59", username: example1, active: "false", approv…

[mattdm (Matthew Miller)]

Eh bien, en quelque sorte. Comme le dit l’OP dans ce sujet, en réponse à cela…

@dmccann

J’essaie d’éviter de créer un compte utilisateur à part entière et de choisir un nom d’utilisateur. Essentiellement, je veux reproduire ce qui se passe dans le déclencheur d’e-mail (« adresse e-mail entrante personnalisée » dans les paramètres du groupe) où l’adresse e-mail de l’expéditeur sera « mise en scène », de sorte que s’il s’inscrit, il pourra revendiquer tous les messages qui ont été créés en son nom via le déclencheur d’e-mail.

… et là, la réponse est essentiellement d’injecter un e-mail et de laisser le code de gestion des e-mails s’en occuper. Mais cela ne fonctionne pas dans ce cas, car je dois intervenir et désactiver les notifications par e-mail pour l’utilisateur avant de créer la publication.

Il se trouve que nous avons l’option SSO-overrides-username activée pour un côté du pont proposé, donc je pense que la création de quelque chose comme ‘othersite-user’ pourrait être une solution de contournement… mais cela ne fonctionnera pas nécessairement sans ce paramètre SSO.

[supermathie (Michael Brown)]

Si passer staged: true à l’appel de création d’utilisateur admin ne fonctionne pas, je pense que nous serions ouverts à une PR pour l’activer.

(C’est une fonctionnalité quelque peu de niche en dehors de votre cas d’utilisation, je pense ?)

Peut-être pourriez-vous utiliser la route handle_mail pour poster un faux e-mail en tant qu’utilisateur ? (Oh, comme @blake le suggère)

Cela créerait l’utilisateur staged si nécessaire et le sujet en même temps.

[simon]

@mattdm

la réponse consiste essentiellement à injecter un e-mail et à laisser le code de gestion des e-mails s’en charger.

Avec cette approche, il semblera que les utilisateurs ont créé des sujets et des réponses par e-mail. Les utilisateurs staged ne peuvent créer des publications que par e-mail. Vous obtiendrez une erreur d’accès non valide si vous tentez de créer une publication non-e-mail pour un utilisateur staged via l’API.

Quelque chose dans l’approche des utilisateurs staged ne me semble pas tout à fait correct. Il pourrait être utile de sonder vos utilisateurs pour voir s’ils ont des préoccupations. Si vous pouviez obtenir l’autorisation de vos utilisateurs, vous pourriez simplement créer des utilisateurs actifs non-staged sur le site miroir, puis publier leurs sujets et commentaires via l’API.

@supermathie

Si passer staged: true à l’appel de création d’utilisateur admin ne fonctionne pas, je suppose que nous serions ouverts à une PR pour l’activer.

Passer staged: true crée un utilisateur staged. Je suppose qu’un utilisateur créé de cette manière pourra publier par e-mail. Mon site de développement local n’est pas configuré pour envoyer des e-mails à Discourse, je ne peux donc pas le tester pour le moment.

[pfaffman (Jay Pfaffman)]

Je voulais utiliser Discourse comme processeur de formulaires générique pour gérer les formulaires de contact. Je déteste les formulaires de contact, mais certains utilisateurs préfèrent les utiliser plutôt que d’envoyer un e-mail. Même si je pense que ces personnes prennent de mauvaises décisions, j’aimerais leur faciliter le contact pour qu’elles puissent me donner de l’argent.

Ce serait très pratique de pouvoir créer un message qui crée un utilisateur temporaire sans avoir à recourir à un autre système pour traiter le formulaire et envoyer un e-mail.

Je suppose que je devrai créer un plugin pour cela, mais c’est mon plan.

C’est l’une des seules choses qui me restent à régler pour me débarrasser de WordPress.

@simon

Vous obtiendrez une erreur d’accès non valide si vous tentez de créer un message non-e-mail pour un utilisateur temporaire via l’API.

Alors peut-être que dans le plugin, je créerai le message comme s’il s’agissait d’un e-mail. Ce ne sera peut-être pas trop difficile dans un plugin. Et cela rendrait probablement possible via une API.

[nathank (Nathan Kershaw)]

@pfaffman

Il serait très utile de pouvoir créer un message qui crée un utilisateur mis en scène sans avoir à recourir à un autre système pour traiter le formulaire et envoyer un e-mail.

Je pense que vous pourriez utiliser un Assistant ( Plugin d’Assistant Personnalisé) pour y parvenir sans trop de difficulté. Vous pouvez maintenant créer des assistants anonymes. Je serais ravi de vous aider si besoin !

[simon]

@pfaffman

Je vais donc peut-être créer le post comme s’il s’agissait d’un e-mail dans le plugin.

Oui, cela fonctionne : Creating a staged user with an API call - #8 by blake.

[pfaffman (Jay Pfaffman)]

Oh ! Bien sûr. C’est ainsi que le récepteur de courrier distribue le courrier. Je pense que je veux un point de terminaison qui acceptera des champs arbitraires de n’importe quel formulaire, les placera dans un sujet et me les livrera. Cela m’éviterait d’avoir à rendre publique une clé API (limitée à la livraison de courrier, cela ne semble pas si terrible, d’avoir du javascript traiter le formulaire puis le livrer au point de terminaison existant).