Crear usuarios en etapa a través de API?

[mattdm (Matthew Miller)]

Estoy considerando la idea de crear un servicio de puente webhook+API para conectar categorías dadas en dos foros de Discourse diferentes. La idea general sería:

1. Un webhook en cada servidor para eventos de Tema y Publicación^[1]
2. Un oyente que tome estos y replique el evento en el servidor opuesto a través de la API
   • Uh, algo para prevenir bucles, obviamente^[2]
   • Comprobar si existe un usuario con la misma dirección de correo electrónico en el servidor opuesto^[3]
   • Si no existe dicho usuario, crear un usuario provisional
   • Cambiar la configuración de notificación del usuario provisional para que no reciba notificaciones por correo electrónico^[4]
   • Crear o actualizar la publicación bajo el usuario real o provisional apropiado
3. Probablemente una rutina programada para revisar los temas y asegurarse de que nada se haya perdido, y posiblemente reordenar para que ambos lados estén de acuerdo.

Desde Comprensión de los estados, roles y permisos de usuario, creo que los usuarios provisionales harían básicamente lo que queremos: si alguien creara una cuenta con esa dirección de correo electrónico más tarde, podría “reclamarla” e interactuar con todas sus publicaciones como si hubiera estado allí todo el tiempo.

Pero, ¿hay alguna forma de crear un usuario provisional desde la API? No veo eso en Discourse API Docs.

---

1. y posiblemente también eventos de Me gusta y Resuelto, pero no en la primera versión ↩︎

2. Definitivamente pensé en esto antes de escribir esta lista ↩︎

3. usando direcciones de correo electrónico como clave porque los sistemas de cuentas pueden no tener los mismos nombres de usuario ↩︎

4. Vi una publicación sobre esto siendo posible en algún lugar por aquí… ↩︎

[Lilly (Lillian Louis)]

@mattdm

Pero, ¿hay alguna forma de crear un usuario “staged” desde la API? No lo veo en Discourse API Docs.

---

1. y posiblemente también los eventos Like y Solved, pero no en la primera versión ︎
2. Definitivamente pensé en esto antes de escribir esta lista ︎
3. usando direcciones de correo electrónico como clave porque los sistemas de cuentas pueden no tener los mismos nombres de usuario ︎
4. Vi una publicación sobre esto siendo posible en algún lugar por aquí… ︎

¿No estoy seguro si esto es lo que buscas?

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)]

Bueno, algo así. Como dice el OP en ese tema, en respuesta a eso…

@dmccann

Estoy tratando de evitar crear una cuenta de usuario completa y elegir un nombre de usuario. Esencialmente, quiero replicar lo que sucede en el disparador de correo electrónico (‘dirección de correo electrónico entrante personalizada’ en la configuración del grupo), donde la dirección de correo electrónico del remitente se ‘preparará’, de modo que si/cuando se registren, podrán reclamar cualquier mensaje que se haya creado en su nombre a través del disparador de correo electrónico.

… y ahí, la respuesta es básicamente inyectar un correo electrónico y dejar que el código de manejo de correo electrónico se encargue de ello. Pero eso no funciona para este caso, porque necesito intervenir y desactivar las notificaciones por correo electrónico para el usuario antes de crear la publicación.

Resulta que tenemos SSO-overrides-username activado para un lado del puente propuesto, así que creo que simplemente crear algo como ‘othersite-user’ podría ser una solución alternativa… pero eso no funcionará necesariamente sin esa configuración de SSO.

[supermathie (Michael Brown)]

Si pasar staged: true a la llamada de creación de usuario administrador no funciona, sospecho que estaríamos abiertos a una PR para habilitarlo.

(¿Es una característica algo nicho fuera de tu caso de uso, creo?)

¿Quizás podrías usar la ruta handle_mail para publicar un correo electrónico falso como el usuario? (¡Oh, como sugiere @blake (https://meta.discourse.org/t/creating-a-staged-user-with-an-api-call/84667/4?u=supermathie))

Eso crearía el usuario provisional si fuera necesario y el tema al mismo tiempo.

[simon]

@mattdm

la respuesta es básicamente inyectar un correo electrónico y dejar que el código de manejo de correo electrónico se encargue de ello.

Con este enfoque, parecerá que los usuarios han creado temas y respuestas por correo electrónico. Los usuarios provisionales solo pueden crear publicaciones por correo electrónico. Obtendrás un error de acceso no válido si intentas crear una publicación no por correo electrónico para un usuario provisional a través de la API.

Algo sobre el enfoque de usuario provisional no me parece del todo correcto. Podría valer la pena consultar a sus usuarios para ver si tienen alguna inquietud. Si pudiera obtener el permiso de sus usuarios, podría simplemente crear usuarios activos no provisionales en el sitio espejo y luego publicar sus temas y comentarios a través de la API.

@supermathie

Si pasar staged: true a la llamada de creación de usuario administrador no funciona, sospecho que estaríamos abiertos a una PR para habilitar eso.

Pasar staged: true crea un usuario provisional. Supongo que un usuario creado de esta manera podrá publicar por correo electrónico. Mi sitio de desarrollo local no está configurado para enviar correos electrónicos a Discourse, por lo que no puedo probar eso en este momento.

[pfaffman (Jay Pfaffman)]

He querido usar Discourse como un procesador de formularios genérico para manejar formularios de contacto. Odio los formularios de contacto, pero algunos usuarios prefieren usar un formulario de contacto en lugar de enviar un correo electrónico. Incluso si creo que esas personas toman malas decisiones, me gustaría facilitarles el contacto para que puedan darme dinero.

Sería muy útil poder crear un mensaje que cree un usuario provisional sin tener que recurrir a algún otro sistema para procesar el formulario y enviar un correo electrónico.

Supongo que necesitaré crear un plugin para hacer esto, pero ese es mi plan.

Esta es una de las únicas cosas que me quedan por resolver para deshacerme de WordPress.

@simon

Obtendrás un error de acceso no válido si intentas crear una publicación no electrónica para un usuario provisional a través de la API.

Así que tal vez lo que haré en el plugin es crear la publicación como si fuera un correo electrónico. Eso podría no ser muy difícil en un plugin. Y eso probablemente lo haría posible a través de una API.

[nathank (Nathan Kershaw)]

@pfaffman

Sería muy útil poder crear un mensaje que cree un usuario en staging sin tener que recurrir a otro sistema para procesar el formulario y enviar un correo electrónico.

Creo que podrías usar un Asistente ( Plugin de Asistente Personalizado) para lograr eso sin demasiada dificultad. Ahora puedes hacer asistentes anónimos. ¡Estaré encantado de ayudarte si es necesario!

[simon]

@pfaffman

Así que tal vez en el plugin crearé la publicación como si fuera un correo electrónico.

Sí, esto funciona: Creating a staged user with an API call - #8 by blake.

[pfaffman (Jay Pfaffman)]

¡Oh! Claro. Así es como el receptor de correo entrega el correo. Creo que quiero un endpoint que acepte campos arbitrarios de cualquier formulario, los inserte en un tema y me los entregue. Eso me evitaría tener que hacer pública una clave API (con el alcance de solo entregar correo, no parece tan terrible tener JavaScript procesando el formulario y luego entregándolo al endpoint existente).