Di algunos antecedentes sobre el caso de uso en Restrict exposure of full name to certain groups. Estamos utilizando Discourse para facilitar la discusión sobre la escolarización pública local; la base de usuarios objetivo son principalmente padres y otros miembros de la comunidad local. Queremos lograr un equilibrio:
Por un lado, hacer que el sitio sea abierto a la navegación anónima (para que los motores de búsqueda puedan indexarlo, para que sea accesible incluso para los no miembros, para que sea abierto/transparente por principio, …)
Por otro lado, evitar hacer innecesariamente información de identificación personal disponible para rastreadores y visitantes ocasionales no miembros: queremos permitir que las personas compartan sus nombres dentro de la comunidad y queremos abordar la reticencia que muchas personas tienen al hacerlo.
Originalmente, parecía que deshabilitar “Mostrar nombre en las publicaciones” y habilitar “Ocultar perfiles de usuario al público” se encargaría de bloquear las fugas de nombres a usuarios anónimos, pero luego nos dimos cuenta de que no es así. (Y ya les prometimos a las personas a través de los Términos de Servicio y las Preguntas Frecuentes que lo haríamos. )
Denegar el acceso al nombre completo solo a los usuarios anónimos haría el trabajo. Pero, dado que es igual de fácil vincular el acceso a la membresía del grupo, supongo que podría hacerlo, lo que abre la posibilidad, en nuestro sitio, de restringir el acceso a >=TL1, lo que es aún mejor. (Actualmente, requerimos una invitación para registrarnos, pero queremos deshacernos de eso).
Al investigar este problema/tema, he visto otras menciones de solicitudes iguales o similares, por ejemplo, “solo queremos que tal o cual grupo pueda ver los nombres”… así que esto también se encargaría de esos usos.
Una pregunta para ti (¡que incluso podrías considerar una pregunta de producto!):
¿La configuración enable_names pretende significar “No mostrar nombres completos a los usuarios” o más bien “Este sitio no utiliza nombres completos, punto”?
Tengo la sensación (por el propio código y por temas/problemas como este) de que hay una falta de claridad subyacente en este punto, y algunas personas lo han entendido de una manera y otras de otra.
De acuerdo. Los administradores deberían poder acceder al Nombre Completo sin tener que activar y desactivar la opción. Hay razones particularmente importantes (al menos para nuestro foro) para ocultar los nombres reales.
Gracias a todos los que han contribuido a este hilo. Solo quiero preguntar respetuosamente si este problema se abordará en una próxima versión, o al menos se reconocerá como una regresión conocida.
Deshabilitar la opción de activar nombres actualmente rompe la funcionalidad clave de administración de una manera que parece no intencionada, y la falta de claridad sobre si esto es por diseño o un error está dificultando nuestra planificación. Para aquellos de nosotros que gestionamos sitios en producción donde los nombres de usuario son preferibles a los nombres completos, esta limitación introduce fricción real y un comportamiento inesperado.
Entiendo que las prioridades deben equilibrarse, pero sería increíblemente útil obtener una actualización del equipo sobre si esto está en el radar. Gracias de antemano por cualquier información que puedan proporcionar.
Hola, @tobiaseigen, ¿alguna aportación de ingeniería sobre esto? (Han pasado 3 meses, pero yo también estaba ocupado con otras cosas y perdí la pista de esto, así que no me puedo quejar).
Podría empezar a enviar pull request esta semana para hacer la conversación más concreta, pero me preocupa que queden sin revisar y también me vendría bien recibir comentarios sobre algunos aspectos de mi enfoque.
@RGJ@chrismalone y @mdoggydog Muchísimas gracias por su aportación aquí. Seguimos necesitando esta solución y agradecidos por todos los que trabajan en el problema.
Sí, la verdad es que me sorprende que esto no haya tenido más atención. Entiendo que uno dude en hacer una PR sin saber si será revisada y potencialmente implementada.
Aunque imagino que una PR podría convertirse en un plugin, pero entonces limitaría esta opción más a los auto-hospedados.
@mdoggydog Parece que tu solución aquí es reemplazar la configuración enable names (habilitar nombres) con una que tome una lista de grupos, y los nombres de los miembros solo son visibles para esos grupos.
Ten en cuenta que esto aún debería respetar la configuración display name on posts (mostrar nombre en las publicaciones) (y cualquier otra similar que pueda existir), por lo que incluso los grupos permitidos no ven el nombre en las publicaciones si esa configuración está desactivada.
Además, algunas otras cosas que necesitamos corregir/cambiar aquí como efectos indirectos:
Los nombres siempre deben ser visibles en la vista de administración de un perfil de usuario. Este será el caso independientemente de cualquier configuración.
Los nombres solo deben mostrarse en los correos electrónicos si el usuario está en un grupo permitido.
Lo anterior debería solucionar los problemas actuales, además de hacer que esta función sea más flexible y útil.
¿Suena eso a lo que estás proponiendo aquí? Si es así, definitivamente estaríamos encantados de echar un vistazo a cualquier PR (Pull Request) que envíes con esta actualización incluida.
El código que he escrito no elimina la configuración enable names,[1] sino que se suma a ella:
Añadir una configuración full_names_visible_to_groups (que incluye admins y moderators como valores obligatorios).
Añadir un método can_see_full_names? a Guardian, que realiza un “y” de enable_names y la membresía del grupo en full_names_visible_to_groups.
Usar este nuevo método en todos los lugares apropiados donde un nombre completo se expone/emite desde el servidor.
1 y 2 fueron fáciles. 3 es más complicado, y sé que me encontré con algunos obstáculos que no estaba seguro de cómo resolver sin obtener asesoramiento/orientación. Necesito volver a revisar mi código y mis notas en profundidad. (Han pasado más de 2 meses desde que me sumergí en esto. )
(Si mal no recuerdo, display name on posts y similares son configuraciones del lado del cliente, que afectan la presentación de los datos recibidos del servidor. En otras palabras, una restricción sobre lo que sea que el servidor emita.)
Creo que (1) está cubierto si enable_names es verdadero, lo cual probablemente será lo que casi todos querrán una vez que la nueva configuración por grupo esté disponible.[2]
Creo que encontré y me ocupé de (2) — en su mayoría.[3]
Recuerdo algunos otros casos en los que se filtran nombres completos.[4]
De todos modos, revisaré mis notas e intentaré enviar PRs esta semana, y sacaré a la luz las preguntas abiertas/cabos sueltos en el proceso.
…por una serie de razones, entre ellas: (a) no estaba seguro de cuál era la intención real de la configuración (ver mi pregunta en una publicación anterior), y (b) dejarla en su lugar proporciona una ruta de actualización incremental más segura. ↩︎
…si se adopta la postura de que enable_names = false significa “Este sitio no utiliza nombres completos de ninguna manera”. ↩︎
Por ejemplo, cuando se envía un correo electrónico de invitación a alguna dirección (obviamente no asociada con un usuario, de lo contrario no necesitarían invitación), ¿el correo electrónico incluye el nombre completo del remitente o no? ↩︎
Por ejemplo, oneboxer.rb, al hacer oneboxing de un usuario local, escribe el nombre completo en el contenido de la publicación cocida, lo que lo hace visible para todos y cualquiera, para siempre. ↩︎
Esta PR es un requisito previo para la(s) siguiente(s), asegurando que las instancias de Guardian se pasen realmente de un serializador a otro. Los detalles están en la PR/mensaje de commit. La conversación sobre esta PR podría comenzar mientras preparo la siguiente.
Mi Aventura Mini en GitHub
…bueno, estaba allí hasta que escribí la URL en el cuadro de edición aquí… y entonces toda mi cuenta fue suspendida de repente.
He presentado una solicitud de reactivación y actualizaré esto cuando tenga una actualización.
13 horas después, recibí un correo electrónico que decía, básicamente: “A veces sucede esto; todo está bien ahora”. Muy kafkiano. Mi cuenta desapareció del sitio, hasta el punto de que las publicaciones que había hecho en Issues/PR hace años se desvanecieron, dejando misteriosas conversaciones unilaterales, con unos pocos bloques de citas fantasmales como única evidencia de que alguien más (yo) había estado allí.
Esto parece horriblemente exagerado, no solo para la cuenta suspendida, sino también para todos los proyectos a los que se les han despojado silenciosamente partes de su historial.
Me estoy dando cuenta de que esto también va a implicar la coordinación de cambios en los repositorios de plugins de Discourse, lo que significa una cadena de PRs (pull requests), en una especie de orden de dentro hacia fuera, para asegurar que las pruebas siempre pasen (y, por supuesto, que main esté siempre funcional).
Me imagino que la secuencia se vería así (donde CORE significa “PR en discourse/discourse” y PLUG significa “PR(s) en los repositorios oficiales de plugins”):
Imponer el reenvío del ámbito del serializador (no se espera ningún cambio funcional)
a. CORE Implementar la comprobación del ámbito del serializador, desactivada por defecto
b. PLUG Arreglos para el reenvío del ámbito
c. CORE Arreglos para el reenvío del ámbito, y activar la comprobación del ámbito por defecto
Proporcionar preventivamente Guardians (reemplazando los marcadores de posición) en los lugares necesarios para la Fase 4 (no se espera ningún cambio funcional)
CORE Arreglos de marcadores de posición
PLUG Arreglos de marcadores de posición
Implementar un simple Guardian#can_see_full_names? que solo dependa de enable_names(no se espera ningún cambio funcional)
CORE Añadir método a Guardian
Usar can_see_full_names? dondequiera que se emita el nombre completo (reemplazando el uso directo de enable_names según corresponda) (podría tener un cambio funcional)
CORE usar el nuevo método Guardian
PLUG usar el nuevo método Guardian
Implementar el ajuste full_names_visible_to_groups(cambio funcional)
CORE Añadir un nuevo ajuste a la configuración, y comprobar el ajuste en el método Guardian
(1) y (2) se reducen a asegurar que los Guardians se utilicen de forma más consistente y fiable en todo el código base de Discourse.
(3) y (4) tratan de instituir una abstracción más precisa para controlar cuándo los nombres completos son expuestos por el backend (decidiendo sobre la exposición dependiendo del contexto que represente el Guardian).
(5) es finalmente la parte (relativamente trivial) en la que la exposición del nombre completo está controlada por la pertenencia a un grupo.
Lo siento, pero tengo que rechazar este PR. Ese cambio es demasiado complejo y difícil de mantener. Las razones principales son:
El ámbito (scope) no siempre es necesario y no debe ser forzado;
Cambiarlo y mantenerlo posteriormente en todos los lugares, como los plugins, sería una cantidad enorme de trabajo;
PlaceholderGuardian no resuelve el problema sino que añade un ámbito falso (con la intención de arreglarlo más tarde);
La mayoría de las veces, la serialización debería ocurrir en el controlador, y el ámbito se añadirá automáticamente.
Mostrar un nombre de usuario o un nombre completo basado en el grupo es bastante complicado. En lugar de intentar fusionarlo en el núcleo de Discourse, ¿podemos empezar creando un plugin? Si tu comunidad es pequeña, así es como puede funcionar:
Establece SiteSetting.enable_names en false para usar siempre el nombre de usuario;
Define un endpoint que devuelva un mapa de nombre de usuario → nombre completo para usuarios TL3;
Ya terminé un PR que resuelve el problema original. El administrador siempre podrá ver el nombre completo y editarlo. Intentaremos fusionarlo a principios de la próxima semana
Creo que todavía hay un malentendido/desacuerdo fundamental sobre lo que se supone que debe hacer la configuración enable_names, lo que se reduce a esta pregunta:
¿La configuración enable_names tiene la intención de significar
“No mostrar nombres completos públicamente”.
“Este sitio no utiliza nombres completos, y punto”.
Creo que algunas personas en este tema piensan que hace (1) y otras piensan que hace (2). Mi impresión es la segunda, que enable_names decide si el sitio utiliza o no nombres completos.
Tenga en cuenta que cuando enable_names está desactivado:
El cuadro de diálogo de registro no ofrece el campo de nombre completo.
Los usuarios no ven el campo de nombre completo en su propia página de preferencias de cuenta; los usuarios nunca ven su propio nombre completo en ningún lugar.
No entiendo el caso de uso de un sitio en el que los administradores, y solo los administradores, son las únicas personas que saben que existe un campo de nombre completo en el sistema. Mi falta de imaginación me hace dudar de que alguien aquí realmente quiera eso. Si alguien quiere esto, ¡por favor, ilumínenme!
(Creo que también hay algún malentendido sobre lo que mi borrador de PR está tratando de lograr, y cómo, y por qué, pero primero quería abordar la pregunta “¿Qué hace realmente enable_names?”)
Sí, puedo nombrar numerosos ejemplos. A menudo, la empresa propietaria de la comunidad tiene el derecho legal (y/o la necesidad) de conocer los nombres de sus clientes, pero las leyes de privacidad le prohíben publicar esos nombres a terceros. Es prácticamente lo mismo que por qué usar CC en un correo electrónico masivo es un no-no y se supone que debes usar CCO.
Bueno, esto comenzó como un informe de error bastante simple donde simplemente se comportaba mal. Y luego todos entramos en una discusión sobre lo que se suponía que debía hacer, lo que también causó mucha confusión y discusión adicional. Lo cual está bien, pero habría sido mejor en un tema de Feature.
Es el #1. La descripción de la configuración dice:
Mostrar el nombre completo del usuario en su perfil, tarjeta de usuario y correos electrónicos. Desactivar para ocultar el nombre completo en todas partes.
El hecho de que el nombre completo esté oculto implica que existe, y los administradores pueden ver cosas ocultas.
También están display_name_on_posts, full_name_requirement y display_name_on_email_from.
Si quieres el #2, supongo que tendría más sentido basarse en full_name_requirement y añadir una opción ‘Nunca’ allí.
(Y sí, estoy de acuerdo en que enable_names debería llamarse de otra manera, pero renombrar la configuración nunca es divertido). Y también estoy de acuerdo en que
¿Solucionará esto la función original? Es decir, ¿el administrador y el usuario pueden ver su nombre completo? Simplemente parece que este cambio inicialmente ha causado muchos problemas en comparación con la función original. Incluso el moderador completo debería tener una opción para ver el nombre real a través de una configuración, ya que en algunos casos de uso esto podría ser deseado/necesario.
Después de que el equipo implementó este cambio, los usuarios que habían ingresado su nombre real quedaron en blanco.
En mi opinión, esta configuración debería haberse separado en 2 configuraciones con definiciones claras. Con la nueva función para deshabilitar nombres como una nueva configuración para desactivar los nombres reales.
Tengo la suerte de tener una comunidad pequeña. Imagina un sitio con miles de miembros cuyos nombres reales se han quedado en blanco.
)
)
