Sin embargo, existen casos de uso para comunidades grandes como la mía en las que tenemos literalmente foros más pequeños dentro del principal. Piensa en los Clanes en la cultura de los videojuegos.
Estas subcomunidades adoptan las reglas principales del foro, pero luego también tienen algunas reglas adicionales específicas y un equipo dedicado que se encarga de moderar la sección, además de liderarlas, pero eso es secundario.
Los moderadores de categoría no pueden actuar sobre los Usuarios en sí, solo sobre la categoría, sin embargo, en mi caso de uso, deberían poder impedir que algunos usuarios participen si rompen algunas de sus reglas de subforo.
Todo lo que realmente necesito es saber si podría haber suficiente granularidad en las funciones principales para permitir que los moderadores de categoría bloqueen a usuarios específicos para que no accedan a su categoría.
La forma en que lo imagino es que se genera una tabla personalizada que agrega tanto el category_id como el user_id y, cuando un usuario intenta acceder a un tema o categoría específica, simplemente se verifica también en esa tabla.
¿Estoy muy lejos de mi objetivo? ¿Sería factible? Tengo mucha experiencia en desarrollo de software pero casi nada con Ruby, así que realmente no sé por dónde empezar a buscar en el código fuente de Discourse para entender dónde debería buscar
Podrías permitir que solo los miembros de la categoría del clan publiquen y eliminar a los usuarios que no deseas que estén en la categoría. Esto requeriría que todos los que deseas que estén en la categoría sean miembros de ese grupo.
He hecho lo mismo. Y como no dejo que nadie suba automáticamente por encima de TL2, fue una solución mental y administrativa muy fácil y sencilla. También tenía un toque de elegancia
Lo hice para un cliente hace un tiempo. Los niveles de confianza no iban a funcionar para nosotros, así que en su lugar creamos grupos privados por categoría en los que cada usuario se aprovisionaba automáticamente, y los moderadores de categoría eran los propietarios.
Las “prohibiciones” eran tan simples como eliminar dichas membresías, lo que significaba cero trabajo por parte de la administración.
Un poco más de esfuerzo para empezar, pero efectivamente cero después.
Ejemplo: uno de mis clientes tiene un foro con una categoría “En Venta”, accesible para TL2 y superior.
Quieren prohibir que ciertos miembros creen temas allí, pero necesitarían copiar y mantener un grupo que contenga a las mismas personas que TL2 menos 5 usuarios específicos.
Presumiblemente de la misma manera, ¿proporcionar usuarios a grupos basándose en un criterio (¿detectar promoción a TL2?) y luego eliminarlos si es necesario? El hecho de que TL2 sea el criterio de entrada no significa que tengas que depender de ese estado TL2 para determinar la membresía, ¿verdad? También depende de si tienes el tiempo y los recursos para diseñar algo en/alrededor de tu instancia.
No sugerí que fuera una solución única para todos. Puede que no funcione para su caso de uso si no quieren hacer el trabajo extra, pero para el ejemplo con mi cliente y el escenario en el que una instancia se está dividiendo en gremios/clanes/lo que sea, podría ser una buena opción.
Pero si estamos diseñando algo en la instancia de todos modos, entonces preferiría tener la funcionalidad de prohibición de categorías
También hace que las cosas sean más mantenibles. Si tengo 50.000 usuarios y necesito que todos ellos puedan acceder a la categoría excepto unos pocos, entonces es difícil obtener una lista de esos pocos.
Quiero decir, prohibir es solo otra palabra para exclusión, y Discourse en realidad no tiene un permiso de exclusión en absoluto. ¿Necesita existir cuando “no inclusión” es efectivamente lo mismo? Me gusta el modelo de permiso explícito, hace que la solución de problemas sea indolora.
Todavía tengo alguna pesadilla ocasional al intentar resolver el modelo de permiso/denegación de vBulletin hace todos esos años. Lo único que he experimentado con más dolor y deuda asociados es RSOP.
Agradezco todas las aportaciones de soluciones alternativas, pero hice una pregunta técnica específica, no alternativas que supongan compromisos con lo que estoy intentando averiguar
@crius sería factible con un plugin, creo que puedes llegar bastante lejos en el lado del cliente anulando los permissions en el serializador de categorías, y en el lado del servidor añadiendo una comprobación adicional usando NewPostManager.add_handler.
¿Has considerado usar grupos? Crea una categoría con 2 grupos para el acceso. 1 Grupo son tus moderadores de categoría. El Otro son tus participantes en el subforo. El grupo de participantes debe solicitar acceso al área del subforo. Tus moderadores de categoría, algunos o todos, son los propietarios de ese grupo. Si un miembro infringe las reglas y requiere que sea expulsado del subforo. Expúlsalo del grupo de participantes y comunícate con otros moderadores de categoría sobre la duración.
Bueno, entonces, desafortunadamente, es posible que necesites considerar patrocinar un plugin. Aquí es donde la financiación colectiva de plugins sería un gran concepto. El equipo principal podría agregar eventualmente algo como lo que estás solicitando, pero podría pasar algún tiempo debido a las prioridades de la lista de desarrollo.
Por otro lado, con la sugerencia de grupo, podría ser posible con un componente temático agregar una opción de expulsión del grupo.
¿Estás totalmente seguro de que hiciste la pregunta correcta
Quiero decir, tu objetivo principal es resolver un problema, y la prohibición de categorías es solo tu respuesta no resuelta para eso. La pregunta correcta sería cómo resuelvo el problema X y cuáles son mis opciones.
Evalué la posibilidad de gestionar esto con TL o grupos de usuarios, pero aumentará la carga de trabajo de los moderadores, lo cual simplemente no es factible en comunidades grandes.
Los grupos de usuarios, en particular, son perjudiciales para una experiencia de usuario ágil.
No necesito solicitar un patrocinio, ya que tengo mucha experiencia como ingeniero de software y otras personas que también tienen mucha experiencia. Simplemente no usamos Ruby, por lo que esa será la única ralentización.
Gracias por las aportaciones de todos modos. Aprecio que este foro tienda a ser muy dogmático, pero en lo que respecta al software en sí, sería mejor simplemente seguir un enfoque que sea más “dar la opción” con, por supuesto, una complejidad de código adicional en el otro extremo de la balanza.
