Estamos intentando crear un discurso específico de la región, donde la membresía de un usuario lo limitará a ciertos grupos, pero actualmente esto entra en conflicto con el soporte de usuarios anónimos porque los usuarios anónimos no tienen ninguna asociación de grupo.
Esta PR añade asociaciones de grupos a usuarios anónimos.
He considerado los ataques de desanonimización y tienes razón: la herencia de grupos de usuarios no es una herramienta para todos y es especialmente vulnerable en instancias con afiliaciones de grupo de alta cardinalidad. Como se detalla en el PR, el concepto original para admitir publicaciones anónimas en grupos regionales, que implícitamente tendrán una baja cardinalidad en nuestra instancia.
edición: He agregado un atributo de grupo llamado anonymous_user_inheritance, que permite a los administradores elegir si el grupo es heredado por usuarios anónimos o no. También he agregado una advertencia junto a la configuración de administrador para habilitar la función, y estoy abierto a cualquier sugerencia adicional.
Realmente no hay una categoría para solicitar revisiones de código, como tal, por lo que esta es probablemente la mejor para ello.
Los PRs (Pull Requests) a menudo son bienvenidos, aunque es bueno confirmar que es una dirección/característica que Discourse quiere seguir antes de profundizar demasiado.
Alternativamente, podrías considerar introducir esta característica en un plugin para que esté disponible sin incorporarla al código principal.
¡Gracias por el consejo! Un plugin se adaptaría bien a nuestros usos, excepto que este cambio requiere una migración de base de datos. ¿Sería factible una migración en un plugin?
Sí, pero en mi opinión es una mala práctica modificar tablas principales en un plugin.
Si mueves esto a un plugin, es mejor usar group_custom_fields o tu propia tabla designada.
En este caso específico, también podrías (en su lugar) agregar una configuración del sitio como “grupos heredados permitidos” y hacer que el administrador seleccione todos los grupos que se pueden heredar en esta única configuración. Eso mantendría las cosas mucho más simples y agruparía toda la funcionalidad proporcionada por el plugin en un solo lugar.
¡Gracias por tus comentarios, Richard! ¿Podrías ayudarme a entender tu segunda propuesta?
que el administrador seleccione todos los grupos que se pueden heredar en esta única configuración
Para verificar mi comprensión, ¿tu sugerencia es tener la configuración general del sitio para permitir la herencia de grupos y luego, en la página de configuración de cada grupo individual, habría una casilla de verificación para indicar si este grupo es heredable o no, de modo que sea similar a lo que tengo ahora, excepto que se elimina la configuración redundante?
que el administrador seleccione todos los grupos que se pueden heredar en esta única configuración
¿Estabas sugiriendo lo anterior, o tenías algo más en mente? Mi idea original era construir una especie de herramienta de selección donde hubiera un menú de casillas de verificación o algo así, pero eso se volvió complejo de implementar muy rápidamente.
¡Gracias por el consejo sobre los plugins! Tendré en cuenta la opción de plugins en futuras contribuciones.
No, sugiero que no hagas de esto una configuración en la página del grupo, sino una configuración general del sitio que contenga todos los grupos que son heredables en su lugar.
Una configuración similar es Administrador - Configuración - Usuarios - grupos permitidos para publicaciones anónimas. No es una casilla de verificación en la página de configuración de cada grupo “permitir publicaciones anónimas para este grupo”, es una configuración con todos los grupos que permiten publicaciones anónimas,
o Administrador - Configuración - Publicaciones - grupos permitidos para menciones aquí en lugar de una casilla de verificación en la página de configuración de cada grupo “permitir menciones aquí para este grupo”.
Es más fácil de implementar, genera menos desorden en la base de datos y proporciona una mejor supervisión al administrador del foro.