Se ha añadido una nueva opción de configuración llamada invite_code.
Cuando se establece, todas las cuentas que se registran deben ingresar el código de invitación para poder crear una cuenta. Los usuarios que no tengan este código no podrán registrarse.
Esta función es 100% opcional. Por el momento, solo es compatible con la autenticación local, pero mejoraremos esto en futuras iteraciones.
Si activas el código de invitación global, se aplicará; si no, no se aplicará y el código de invitación no aparecerá en el cuadro de diálogo de registro.
Esto requiere una moderación manual de cada cuenta. Esta configuración es realmente muy útil para quienes desean probar con unos pocos usuarios o para quienes organizan algún tipo de promoción en la que el acceso al foro sea un beneficio. Un código de invitación de este tipo reducirá casi drásticamente la carga de trabajo en los foros de proyectos piloto.
Porque necesito aprobar cada correo electrónico y estar en la cola de aprobación las 24 horas del día, los 7 días de la semana, y no tengo ni idea de si se trata de un bot aleatorio que se registró o si realmente es alguien que debería tener acceso.
Con un código de invitación, sé que al menos tuvieron un código de invitación que compartí de forma privada.
+1 para esta función, que es enormemente útil para varias comunidades que gestiono. Entiendo el punto de @codinghorror y @ondrej sobre la aprobación manual mencionado anteriormente, pero creo que esto cubre un vacío que existe entre invitar manualmente a todos (sitio ‘solo por invitación’) y aprobar manualmente a todos los usuarios (sitio ‘aprobar usuarios’).
No queremos aprobar usuarios. Solo queremos publicar un código en un grupo de Slack/Telegram/WhatsApp y permitir que todos lo usen. A veces, tener algunos probadores adicionales antes del lanzamiento oficial no hace mucho daño.
También encuentro esto muy útil, especialmente si la funcionalidad se amplía ligeramente para que sea posible “asociar” grupos a un código de invitación específico; es decir, que alguien que cree una cuenta usando un código específico se añada automáticamente a un grupo determinado.
En algunos casos de uso, esto también podría resolver la solicitud de tokens de invitación independientes del correo electrónico, que surge de vez en cuando…
Soy fan de esto en formas ligeramente diferentes, solo necesita algunos ajustes. Si hay una necesidad urgente (?) de ello ahora, entonces supongo que está bien.
Simplemente no siento personalmente que la magia dominio …
por favor regístrate en https://forum.this-is-my-magic-domain.org
sea un nivel de protección de registro completamente inutilizable y totalmente inviable en comparación con la magia contraseña …
debes conocer el secreto this-is-my-magic-password para acceder a este sitio
Hay dos formas de esto que estoy encantado de apoyar
Por favor, visita amazing.forum.com e ingresa el código de invitación: fantastic para obtener acceso (implementado)
Y
Por favor, visita amazing.forum.com/register?code=fantastic para registrarte y obtener acceso al foro
Probablemente hemos superado la regla del 100 aquí, dado que nuestra forma general de resolver este problema consiste en colocar sitios detrás de autenticación HTTP básica.
Ambas son bastante similares; implementaré la #1 por ahora, pero seguiré con la #2.
La #1 tiene la ventaja de que es un poco más fácil cuando no dependes del copiar y pegar, por ejemplo, recibir instrucciones por WhatsApp y luego usar el escritorio para completar.
La #2 tiene la ventaja de que reduce la escritura de fantastic y es útil para compartir por “correo electrónico” en comparación con compartir por WhatsApp.
¿No estás seguro de dónde surgió forum.this-magic-domain.org aquí? En ambos casos, se trata exactamente del mismo dominio en el que está el foro.
(Esto está en un sitio de desarrollo con must_approve_users activado, después de la validación por correo electrónico)
Debería ser opcional al registrarse y opcional al iniciar sesión mientras no esté aprobado, ya que cualquier cosa que obligue a todos los usuarios a copiar el código alrededor va a fallar y necesitará intervención del administrador.
Ahora me doy cuenta de que simplemente reiteré por error los puntos de @codinghorror del tema anterior. (los cuales no había leído al momento de escribir esto, ya que esto estaba en #feature:announcements)
Esencialmente, esto debería construirse sobre must_approve_users + login_required en lugar de crear un sistema completamente paralelo. La implementación actual está bien como una solución temporal para superar la crisis actual, pero debería corregirse.
Alguien olvidará el código o no lo anotará si lo presentas en una conferencia. O necesitarás cambiar el código después de que los videos de la conferencia se publiquen. Es mucho mejor preguntar en tu grupo de WhatsApp “¿de quién es la cuenta @test3?”, obtener una respuesta afirmativa y hacer clic
en lugar de intentar guiarlos para que copien el código correctamente en el formulario de registro. (nota: estas capturas de pantalla son después de la validación del correo electrónico.)
Creo que está bien, solo necesitamos llegar a los ajustes finales. Definitivamente hay algunas mejoras que apoyo plenamente aquí.
Primero, integración con la página de invitaciones de usuarios, por ejemplo, si te registras en Meta visitando el enlace https://meta.discourse.org/signup?u=codinghorror, aparecerás como alguien que invité en mi página de perfil de usuario, así:
Recuerda que las invitaciones basadas en correo electrónico ya otorgan TL1 a los usuarios que invitas… así que ya tenemos esa ventaja… revisa el cuadro de diálogo de invitación… fíjate que también puedes agregar acceso a grupos, y el aumento de TL es implícito. Probablemente deberíamos explicarlo claramente en el texto de este cuadro de diálogo, en realidad:
Segundo, deberías poder generar enlaces de invitación sin correo electrónico desde el mismo lugar donde envías invitaciones, según lo mencionado arriba … esto resuelve completamente el problema de “pero no conozco sus direcciones de correo electrónico ”.
Tercero, creo que está bien que un sitio sea “solo por invitación” y que las invitaciones sean todas en forma de hipervínculos más una contraseña secreta. De esa manera es:
algo que tienes (por ejemplo, un enlace a un sitio)
algo que sabes (por ejemplo, la contraseña open sesame)
Y si tu sitio tiene aprobaciones, la contraseña secreta te permite saltarte la aprobación también. Si no tienes aprobaciones, no puedes entrar sin la contraseña secreta…
Mi principal problema es que no estamos integrando con las funciones existentes aquí, sino añadiendo algo aleatorio a través de una configuración de sitio oscura. Pero podemos integrar para hacer la función de invitación aún mejor, en lugar de ser una configuración de sitio independiente y extraña.
… esto resuelve completamente el problema de “pero no conozco sus direcciones de correo electrónico 
”.