Nueva función de solicitud 'aceptar invitación' causa problemas con los enlaces de invitación

Hemos estado utilizando enlaces de invitación para ayudar a nuestros usuarios a moverse entre plataformas y a Discourse; sin embargo, el nuevo aviso que comenzó a aparecer con la última actualización de Discourse está causando retrasos y confusión.

Los usuarios que utilizan un enlace de invitación que redirige a una publicación de tema no solo pueden usar el enlace una vez, lo cual es un problema importante si esperamos que lo usen cada vez que quieran visitar la publicación del tema. Es importante que podamos redirigir a los usuarios utilizando el mismo enlace de invitación tantas veces como el usuario desee volver a visitar el tema y que esta función bloqueada por el nuevo aviso esté causando un problema.

También aparecieron otros problemas técnicos. En primer lugar, el botón “aceptar invitación” tarda al menos cinco segundos en responder al clic y luego tarda un tiempo en redirigir al usuario al tema. En segundo lugar, con esta nueva adición, se tarda más en cargar el aviso primero. En tercer lugar, ¡incluso si ya has hecho clic en el enlace de invitación antes y has aceptado la invitación, te lo seguirá pidiendo cada vez que hagas clic en el enlace!

Para reproducir este problema, crea un enlace de invitación que redirija a los usuarios a una publicación de tema y/o los agregue a un grupo. Haz clic en el enlace de redirección mientras inicias sesión en tu cuenta de Discourse.

Por favor, ¿hay alguna forma de desactivar este aviso desde la configuración? Esto es tanto urgente como importante porque para nosotros afectará la experiencia del usuario.

También podría pasar desapercibido para otros que podrían depender de los enlaces de invitación pero que no son conscientes de este nuevo cambio porque no hubo ninguna notificación sobre este cambio, ¡gracias!

2 Me gusta

Me gustaría añadir que también hay un error aquí y, en nuestro caso de uso, no necesitamos el aviso en primer lugar, ¿así que sería posible eliminarlo? ¿o que se ofrezca la opción en la configuración de administración para deshabilitarlo?

El error es que si haces clic en “Aceptar invitación” por segunda vez, la página permanecerá estática y no mostrará ningún mensaje. Esto no es nada útil. Impide que el usuario utilice el contexto anterior para ser redirigido de nuevo al tema. Este es un problema importante. Si pongo un enlace de invitación en un documento y espero que el lector pueda usar el mismo enlace una y otra vez para ser redirigido al tema, el enlace de invitación ya no funcionará. :sob:

Usamos enlaces de invitación porque el participante necesita ser añadido primero a una categoría privada para poder leer el tema. Si el usuario necesita encontrar el tema de nuevo, debería poder usar el mismo enlace de invitación. En este caso, debería aceptar automáticamente la invitación si el usuario ha iniciado sesión, ya que la invitación está destinada a ese usuario y, como funcionaba bien anteriormente, debería redirigir al usuario a la publicación del tema prevista.

Los enlaces de invitación funcionaban perfectamente antes. Espero que puedan echar un segundo vistazo a esto y dar a los administradores la opción de deshabilitar este aviso/mensaje del botón “Aceptar invitación”. ¡Gracias!

4 Me gusta

Gracias por tu informe @gassim.

No puedo reproducir este retraso de 5 segundos. Probé aquí en meta con múltiples invitaciones, tanto añadiendo a un grupo como sin añadirlo. Si ves este retraso cada vez, ¿puedes probarlo la próxima vez con las herramientas de desarrollador abiertas en la pestaña de la consola y ver si se informa de algún error allí?

Puedo reproducir esto, parece que hay una regresión aquí, lo arreglaremos en breve.

5 Me gusta

Aquí hay evidencia del retraso de 5 segundos en la consola de Firefox.

No veo ningún error en la consola de Firefox, pero cuando lo intento en Chrome, a veces obtengo estos errores.

includes.js?v=35a79b300ab5afa978cb59af0b05e059:839

PUT https://XXX/invites/show/XXX.json 502
XMLHttpRequest.send @ includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
send @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:495
ajax @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:471
y @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
O @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
f @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
submit @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926
B._run @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450
B._join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4449
B.join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4412
p @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
a @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2481
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:719
_triggerAction @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:532
click @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:531
trigger @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2235
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
trigger @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4230
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
a @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4234

discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940

SyntaxError: Unexpected token '<', "<html>
<h"... is not valid JSON
    at Function.parse [as parseJSON] (<anonymous>)
    at i (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940:167)
    at discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926:699
    at b (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4291:12)
    at g (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4289:128)
    at h (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4287:107)
    at p.invoke (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4377:192)
    at p.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4369:141)
    at h.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4384:207)
    at B._end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4448:9)
    at B.end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4401:240)
    at B._run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450:118)
    at B.run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4410:13)
    at d (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577:23)
    at u.error (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948:44)
    at l (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:200:118)
    at Object.fireWith [as rejectWith] (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:201:698)
    at E (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:483:468)
    at XMLHttpRequest.<anonymous> (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:494:206)
2 Me gusta

¡Gracias por la ayuda @pmusaraj!

Por favor, el mensaje de aviso no es útil en nuestro caso de uso, ¿hay alguna forma de que los administradores creen enlaces de invitación sin este tipo de aviso?

Los enlaces de invitación se utilizan en un curso donde se invita a los participantes a unirse a los foros de discusión. Todo lo que queremos que haga el enlace de invitación es añadir al usuario a un grupo y redirigirlo a un tema en una categoría privada (sin tener que hacer clic en ‘aceptar invitación’ cada vez que usan un enlace), y después del primer clic se espera que los usuarios puedan volver al tema usando el mismo enlace de invitación. Esto ha estado funcionando sin problemas y perfectamente hasta que el mensaje de aviso se implementó de la noche a la mañana.

He explicado cómo estamos utilizando los enlaces de invitación en otro tema

@tobiaseigen @dan @JammyDodger, por favor, ayúdenme con esto. Debemos poder deshacernos del mensaje de aviso en nuestro caso de uso.

¡Gracias @yanokwa! (:

Hola @gassim, hemos discutido esto internamente. Lo sentimos, pero el comportamiento de aceptar la misma invitación varias veces como el mismo usuario para actuar como marcador es inesperado, y lo arreglaremos para ocultar el botón “Aceptar invitación” si el usuario conectado ya ha aceptado la invitación. En su lugar, mostraremos un mensaje informando al usuario que ya ha canjeado el enlace de invitación.

La aceptación automática de una invitación al abrir la página era un problema de seguridad, por lo que cambiamos a tener la página de introducción “Aceptar invitación” en su lugar.

Si es necesario que el usuario vuelva al mismo tema, sugerimos que lo marque como favorito. O, si tiene algún documento interno donde ponga el enlace de invitación, añada un enlace al tema en el mismo lugar para mayor comodidad.

4 Me gusta

Hola @martin, gracias a ti y al equipo de Discourse por la consideración. Estamos discutiendo soluciones alternativas en este momento.

Sí, por favor, y nos encantaría saber cuándo se soluciona este error.

Entendido… Esperaba que a los administradores se les diera la opción durante la creación del enlace de invitación de elegir si se utilizaba o no el mensaje de aviso (tal vez con una advertencia de lo que podría suceder si no usaban el mensaje de aviso). Somos conscientes de que sin el mensaje de aviso, cualquiera podría acceder al grupo/categoría privada, pero en nuestro caso de uso eso no es un problema porque no son grupos/categorías ‘secretas’, son privadas para mantenerlas separadas como espacios dedicados para la discusión de temas de cursos.

No es fácil exigir a los participantes del curso que marquen el tema, pero la última sugerencia suena como nuestra única opción ahora y la acción inmediata que podríamos tomar para solucionar el problema.

Y parece que también nos enfrentamos a este problema ahora: No 'sign in' option in the accept invitation page, only the signup form is shown, ¡gracias!


Nuevamente, gracias a ti y a tu equipo por todo el trabajo y el apoyo. :+1:

2 Me gusta

Oh, esta es una restricción interesante. Entonces tienes un Discourse con 1000 salas a las que cualquiera puede acceder, pero quieres que los miembros del curso tengan una fuerte afinidad con la sala en particular.

Algunas preguntas:

  • ¿Cuál es el valor de no usar la seguridad aquí? ¿Es latest simplemente una gran cantidad de ruido para el usuario típico? También tenemos una configuración “por defecto, todas las categorías se suprimen de latest” que puede ser interesante.

  • ¿Puede la barra lateral aliviar un poco el dolor? Si tienes la categoría en tu barra lateral, al menos la resalta. ¿Quizás la invitación también debería permitir añadir a la barra lateral? No estoy seguro.

  • ¿Ayudaría explicar mejor las cosas en el tema de bienvenida? Para encontrar tu hogar, por favor marca lo siguiente y añádelo a la barra lateral, aquí están los pasos

cc @mcwumbly

3 Me gusta

¿Por qué no establecer su inicio basado en su grupo principal?

2 Me gusta

Creo que ambos tenemos que aceptar las limitaciones del otro a corto plazo.

Dado que parece que @gassim tenía un sistema implementado que funcionaba bien para ellos, creo que lo mejor es proporcionar una guía que se mantenga lo más cercana posible a eso. Continúe utilizando grupos para controlar el acceso a categorías específicas y limitar el ruido de otros lugares.

Estamos interesados en pulir algunos aspectos de nuestro sistema de invitaciones para hacerlo más mantenible y comprensible, y espero que nos encontremos con problemas como este en el camino. En este caso, insistimos en no depender de los enlaces de invitación como enlaces de temas reutilizables.

Después de leer el tema anterior, creo que lo que más sentido tendría es hacer algo como lo siguiente:

  1. Reemplazar los enlaces de invitación para cada curso con enlaces directos al tema.
  2. Cerca de esos enlaces, incluir un enlace de invitación genérico. “Aún no tienes cuenta? Haz clic aquí para crear una cuenta y unirte al grupo”.
  3. Hacer que el enlace de invitación dirija a un tema que sea una descripción general más genérica e instruya al usuario a regresar a su curso y unirse al tema específico del curso desde allí.
5 Me gusta

Acabo de fusionar esta corrección, debería estar disponible pronto para actualizar tu sitio de Discourse:

Gracias por tu comprensión.

5 Me gusta

¡Gracias por tu interés!

Las salas que se mantienen privadas son para los participantes del curso. Básicamente, queremos que estas salas sean un espacio dedicado sin afectar el resto de la actividad del foro (latest, top… etc.). Tener los foros de discusión del curso en categorías privadas no es porque sean ‘secretos’, sino porque solo aquellos que eligen inscribirse en el curso necesitan ver los temas y la discusión, mientras que aquellos que no lo hacen pueden continuar usando el resto del sitio como de costumbre.

¡Gracias por la sugerencia! Aún no he experimentado con la barra lateral, pero aquí tienes una reflexión sobre por qué no he promocionado la barra lateral todavía:

  1. La página de inicio ya muestra dos columnas: Categorías en una columna y latest en la otra; tener la barra lateral parece una repetición en la página de inicio (¿no hay forma de mantenerla desactivada en la página de inicio?).
  2. La barra lateral parece dar más atención de la necesaria a los Mensajes Privados y no fomentamos mucho el uso de PM.
  3. Contrariamente a la idea de que esto aliviará el dolor, la barra lateral parecerá una distracción para los participantes del curso que se unen a la categoría privada porque no queremos que las otras categorías aparezcan durante su participación. (¿no hay una opción para deshabilitar la barra lateral en algunas categorías?).
  4. Si hay una opción para que el Administrador personalice la barra lateral por ‘grupo’, de modo que los participantes del grupo A vean cosas relevantes para el grupo A, mientras que el grupo B vea cosas relevantes para el grupo B, entonces ayudaría a aliviar el dolor. La razón de esto es que no esperamos que todos los usuarios traten el sitio como si fuera su cuenta de correo electrónico y pasen tiempo aprendiendo a personalizarlo; por otro lado, necesitamos darles la bienvenida donde ya se sientan cómodos y se beneficien directamente de la experiencia sin necesidad de pasar tiempo aprendiendo a personalizar… etc. Así que si podemos personalizarlo previamente para cada grupo y luego ellos tienen la opción de cambiarlo, sería genial (además de la opción de no mostrarlo en la página de inicio - por defecto debería estar oculto en la página de inicio, probablemente un código CSS pueda solucionar esto, pero ¿qué pasa con ciertas categorías?).

No estoy seguro porque habrá al menos 50 temas para los participantes que se inscriban en todos los cursos. Sin embargo, estamos utilizando la sugerencia de @martin:

¡Gracias por la sugerencia @Stephen! Sin embargo, la página de inicio es para todos los miembros y no queremos cambiar eso. Los participantes del curso participarán en varios cursos, pero después de cada curso se les invita a seguir participando en la comunidad.

2 Me gusta

:100::100::100: ¡Gracias!

Entendido, pero entonces esta era la opción del administrador para hacer que el enlace de invitación expire después de un cierto número de usos o después de una cierta fecha (además de limitarlo a direcciones de correo electrónico específicas). Para nosotros, como nunca quisimos que el enlace de invitación expirara, la fecha de expiración fue 2092 y el número de usos fueron 1000000 (y, por supuesto, no especificamos la lista de direcciones de correo electrónico porque queríamos que el enlace de invitación permaneciera abierto a quien realmente quisiera unirse al tema de discusión en la categoría privada). Sin embargo, ahora no veo cómo estas opciones serán tan útiles cuando el enlace expirará de todos modos después del primer uso para cada usuario individual.
Personalmente, todavía creo que si esto se hubiera aplicado de manera diferente al agregar una opción durante la creación del enlace de invitación que sea similar a las restricciones anteriores (por defecto, el enlace de invitación no será reutilizable a menos que el administrador desmarque esta opción y, una vez desmarcada, haya una advertencia sobre el problema de seguridad que preocupa al equipo de Discourse). Habría facilitado todo mucho más desde mi perspectiva. :blush:


:100: ¡Gracias! Este es exactamente el enfoque que estamos tomando actualmente; sin embargo, necesitamos actualizar las pautas con capturas de pantalla y en este momento todavía estamos esperando la corrección que agrega el botón ‘iniciar sesión’ al encabezado: No 'sign in' option in the accept invitation page, only the signup form is shown

¡Gracias @martin!

3 Me gusta