¿Esto está relacionado con el hecho de que la API https://{defaultHost}/invites/link.json dejó de funcionar hoy?
No estoy seguro, ¿podría ser? No estoy familiarizado con este endpoint.
Bueno, ahora estoy recibiendo varios cientos de correos electrónicos informando que nuestra automatización está fallando. Usábamos el endpoint https://{defaultHost}/invites/link y empezamos a recibir errores 404. Revisé la documentación y ahora indica que el endpoint es https://{defaultHost}/invites/link.json (con el .json adicional), pero incluso con ese cambio sigo recibiendo errores 404.
No estoy seguro de cómo solucionarlo. Necesitamos generar enlaces de invitación para enviarlos a través de nuestros sistemas. Todo funcionaba perfectamente hasta hoy.
Además, hacer un PUT a esa dirección devuelve MALA SOLICITUD, pero un PUT a una dirección inexistente devuelve NO ENCONTRADO. No estoy seguro de si esto es una pista de que el endpoint existe y simplemente no funciona.
Quizás debería especificar que tengo una instancia de Discourse alojada por ustedes en https://d.strumenta.community/
Ese punto final de la API se movió a https://{defaultHost}/invites.json mientras consolidábamos las invitaciones por correo electrónico y por enlace.
Ok, entonces creo que la documentación no está actualizada
¿Este endpoint genera un enlace de invitación, pero no envía un correo electrónico?
Porque según la documentación, la diferencia entre /invites.json y /invites/link.json es el envío del correo electrónico.
Además, una solicitud a /invites.json me devuelve BAD REQUEST → mi error, debería usar " en lugar de ’
Con la corrección, obtengo una respuesta indicando que se envió un correo al usuario, y me gustaría evitar eso:
Sería útil recibir una notificación cuando haya cambios en la API y tener acceso a la documentación actual; de lo contrario, las cosas dejan de funcionar de repente y no se puede solucionar…
Agrego esto aquí, solo para visibilidad:
$ curl 'http://localhost:3000/invites.json' -X 'POST' \
-H "Api-Key: d5fc02c5f4efaafacc82e4ff3410ae283d1c5da68ac43430d5133aaf4785593f" \
-H "Api-Username: dan" \
-H "Content-Type: application/json" \
-d "{\"max_redemptions_allowed\":5}"
{"id":18,"link":"http://localhost:3000/invites/6f524dba4ced35ecae709a8614db3b05","redemption_count":0,"max_redemptions_allowed":5,"custom_message":null,"updated_at":"2021-03-10T15:44:44.259Z","expires_at":"2021-04-09T15:44:44.258Z","expired":false,"topics":[],"groups":[]}%
Actualizaré nuestra documentación de la API. Gracias por ponerlo en mi atención y disculpa por las molestias.
Sería genial que create devolviera el enlace de invitación existente en lugar de lanzar un error si proviene del mismo usuario. La respuesta de error 422 es bastante genérica; me llevó mucho tiempo entender por qué fallaban mis pruebas.
Se añadió un PR para recuperar una invitación existente por dirección de correo electrónico: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
Encontré un indicador no documentado skip_email que evita el envío del correo electrónico, por lo que solo tienes que obtener el enlace. Pásalo en el cuerpo junto con el correo electrónico y ¡listo!
{
"email": "someone@test.com",
"skip_email": "true"
}
Realicé algunas pruebas breves y vale la pena mencionar que si lo usas para generar un enlace de correo electrónico, no podrás volver atrás y usarlo para enviar un correo automáticamente; emailed siempre devuelve false una vez que se usa skip_email.
¿Hay alguna razón por la que invites/retrieve no esté en la documentación bajo Discourse API Docs? ¿O me estoy perdiendo algo?
Quiero invitar direcciones de correo electrónico que existen en una base de datos externa, solo si a) ya tienen una cuenta y b) si aún no han sido invitados (este proceso se ejecutará periódicamente y no quiero enviar spam a las personas que no han respondido a su invitación lo suficientemente rápido). invites/retrieve.json parece ser la forma correcta de verificar b) según lo que parece estar en el commit.
Es probable que sea solo una omisión que falta en la documentación de la API, trabajaré para que se añada.
Estaría bien si estos fueran generados por, o al menos probados contra, el núcleo actual de Discourse.
Parecería que debería haber una manera razonablemente simple (lo que probablemente signifique 2 días de trabajo y no la hora que me gustaría creer) de hacer que las especificaciones se ejecuten para probarlos. Oh, ¿o tal vez eso es lo que se supone que hace https://redocly.com/?
Lo que realmente sería útil para mi caso de uso es una forma de recuperar todas las invitaciones enviadas por todos los usuarios. Si “por todos los usuarios” es el punto de inflexión, estaría bien para mi caso de uso recuperar todas las invitaciones (independientemente de su estado).
Con este método me veo obligado a sondear cada posibilidad, que podrían ser 1000 direcciones de correo electrónico cuando probablemente solo hay unas pocas en la tabla.
How to get a password from database? - #3 by pfaffman indica que la base de datos no se expone por defecto, por lo que usar código para acceder a la base de datos desde un proceso externo no es factible directamente, al menos no con mi implementación actual, y quizás tampoco sería una buena idea exponer el puerto de la base de datos en ningún caso.
Estoy tratando de automatizar las invitaciones y la pertenencia a grupos para direcciones de correo electrónico en una base de datos externa.
Y dos veces se refirió al complemento Data Explorer, que también es la respuesta aquí, pero tal vez necesites saber que puedes Run Data Explorer queries with the Discourse API
ah sí, ese era el punto clave que me faltaba, gracias por la indicación


