Los inicios de sesión locales están desactivados (se han configurado los inicios de sesión con Facebook y Google)
El personal debe aprobar todas las cuentas de nuevos usuarios
Contamos con una gran lista de correo electrónico y nos gustaría “aprobar previamente” todas las direcciones de correo de esta lista. Si una persona visita el sitio e intenta registrarse o iniciar sesión con una cuenta de Facebook o Google asociada a un correo en nuestra lista de aprobación previa, no tendrá que esperar a que un miembro del personal la apruebe y podrá comenzar a usar el sitio de inmediato.
Idealmente, también podríamos preconfigurar la pertenencia a grupos por correo electrónico.
¿Es esto posible? Las soluciones que requieran el uso de la API de Discourse son bienvenidas.
Me temo que esto no va a funcionar en absoluto.
Principalmente porque las invitaciones no funcionan sin que los inicios de sesión locales estén habilitados. Así que, probablemente, tendrás que recurrir a un plugin muy personalizado que gestione todo esto o a un sistema de autenticación externo para cumplir con tus requisitos.
Creo que si importas las direcciones con un script de importación, ocurrirá lo correcto. Asegúrate de que esos usuarios no estén marcados como activos, a menos que quieras arriesgarte a inundarlos con notificaciones y resúmenes.
Esto debería ser bastante sencillo desde la consola. Creo que también se podría hacer mediante la API si estás alojado en algún lugar.
“Grande” significa alrededor de 5.000, suficiente para que no queramos escribirlo manualmente en la interfaz de usuario en algún lugar.
@pfaffman, ¿podrías aclarar un poco cómo crearía los usuarios a través de la API? Parece que ‘password’ es un campo obligatorio para crear usuarios, lo que supongo que no se puede hacer si tengo el inicio de sesión local desactivado: POST /users
Para ampliar un poco el caso de uso, para otros que podrían estar considerando algo similar: Queremos animar a los usuarios a iniciar sesión con su cuenta de redes sociales; muchas de las personas con las que trabajamos para involucrarlas en Discourse no son expertas en tecnología y queremos que sepan que no necesitan gestionar otro nombre de usuario y contraseña.
Sin embargo, la función actual de invitación por correo electrónico en Discourse requiere que el usuario elija una contraseña, lo que socava nuestro objetivo de mantener las cosas simples para nuestros usuarios.
¿Quizás hay otra forma de lograr nuestro objetivo? No me opongo a habilitar el inicio de sesión local si es necesario, pero quiero que los usuarios invitados vean claramente que pueden iniciar sesión con redes sociales y no necesitan contraseña en absoluto.
¡Gracias a todos! Estoy muy emocionado de que más personas utilicen Discourse.
Permitir que no creen una contraseña y exigir que te indiquen qué dirección de correo electrónico usan con el inicio de sesión social simplemente no es lo mismo. Todavía pueden omitir tener una contraseña si usan un inicio de sesión social. A menudo me niego a iniciar sesión con mi cuenta de Gmail (aunque con menos frecuencia ahora) y mi esposa casi siempre se niega. Además, el inicio de sesión con correo electrónico es muy útil y significa que nunca necesitas una contraseña. Pero me desvío del tema.
Si la API requiere una contraseña, simplemente genera una aleatoria. Tener una contraseña que no conoces y no necesitas es prácticamente lo mismo que no tener contraseña.
Debo admitir que no me di cuenta hasta una inspección más detallada de que el campo de contraseña es opcional para los usuarios que aceptan invitaciones por correo electrónico. Tienes un punto válido: los usuarios deberían poder elegir si desean usar un correo electrónico diferente y crear una contraseña. Me sentiría mucho más tranquilo si la interfaz de usuario dejara más claro que la contraseña es opcional, especialmente cuando el inicio de sesión con redes sociales está habilitado en el sitio. Con la interfaz actual, alguien tendría que no querer crear una contraseña en absoluto para descubrir que esto no es estrictamente obligatorio, en mi opinión. Supongo que debería ponerme las mangas y crear una solicitud de extracción (PR) para mejorar la experiencia de usuario
Revisé el código de ejemplo, ¡gracias! Por lo que vale, necesité usar este truco para realizar las llamadas a la API correspondientes: Using the API to create a user on an SSO only system - #13 by DylannCordel. Aun así, no creo que esto cumpla con el caso de uso que tenía en mente, ya que desencadena un correo electrónico al usuario para su activación, algo que esperaba evitar a favor de una experiencia fluida que “simplemente funcione” cuando finalmente inicie sesión en el sitio.
También experimenté un poco con esta solución: How to manually add user in discourse? - #10. Creo que funcionaría para añadir manualmente las cuentas de usuario que necesito que existan usando este método, pero en última instancia, no estoy seguro de que valga la pena el riesgo de modificar directamente el entorno dentro del contenedor para realizar estos cambios.
Así que, en resumen, creo que el flujo de trabajo que esperaba no es realmente un flujo de trabajo soportado o esperado, y tendré que conformarme con eso hasta que la interfaz de usuario mejore (quizás) en algún momento.
Los inicios de sesión sociales omiten la contraseña, ya que la autenticación es gestionada por Facebook, Twitter, Google, etc.
Las invitaciones hacen que la contraseña sea temporalmente opcional, pero debes seguir el enlace de invitación nuevamente para “iniciar sesión”, algo que, creo, hemos restringido tanto que, en la práctica, ya no funciona. Después de eso, tendrías que solicitar un restablecimiento de contraseña por correo electrónico para acceder, lo cual requiere establecer una contraseña.
Es una historia larga, pero las invitaciones están diseñadas para que la gente entre y responda lo antes posible con el mínimo de complicaciones, pero NO están pensadas para permitir que las personas omitan establecer una contraseña para siempre.
Enviar una invitación por correo electrónico a un usuario (para que esta opción esté disponible, debe estar habilitado el inicio de sesión local).
Cuando el usuario hace clic en la invitación, puede dejar la contraseña en blanco e iniciar sesión inmediatamente.
La próxima vez que visite el sitio y necesite iniciar sesión, podrá hacerlo con una cuenta social que coincida con ese correo electrónico.
Ahora bien, es justo decir que quizás esto no debería funcionar y que mi comentario anterior sobre una interfaz poco clara es en realidad una característica y no un error diseñado para disuadir a las personas de utilizar este método alternativo. Dicho esto, parece ser una opción aceptable para un usuario que ha sido invitado por correo electrónico pero que, en última instancia, no desea crear una contraseña y prefiere las otras ventajas del inicio de sesión con redes sociales (por ejemplo, copiar su foto de perfil).
Entiendo perfectamente el punto anterior de que algunos usuarios prefieren tener una contraseña en lugar de iniciar sesión con redes sociales, y estoy convencido de que no debo deshabilitar esa opción para quienes la desean. Sin embargo, sigo esperando una forma sencilla y clara de invitar o configurar a usuarios que prefieran no tener contraseña.
