Me gustaría tener alrededor de 20000 grupos en mi instancia de Discourse, ¿es esto posible y afectaría de alguna manera el rendimiento del sitio web?
2 Me gusta
¿Cuántos usuarios tendrás?
¿Qué problema resuelven 20.000 grupos?
2 Me gusta
Aquí está el escenario. Estoy usando Discourse para crear una plataforma de discusión de artículos de investigación. Cada artículo está representado con una etiqueta con el ID del artículo. Todos los temas creados bajo esa etiqueta aparecen en la página de la etiqueta para ese artículo.
El problema es que me falta la siguiente funcionalidad:
Tengo un proceso de aprobación manual para los autores de los artículos que se suben al sistema. Quiero darles la capacidad de editar las publicaciones que están etiquetadas con su artículo. Pero aprendí que no es posible otorgar permisos basados en etiquetas.
Entonces, se me ocurrió tener un grupo por artículo y los autores de un artículo pertenecerán al mismo grupo. Pero ni siquiera estoy seguro de si esto soluciona mi problema porque no estoy seguro de cómo puedo dar la capacidad de editar ciertas publicaciones.
Agradecería saber si existe una forma elegante de tener esta funcionalidad. Gracias.
3 Me gusta
¿Quieres que el autor pueda editar las publicaciones de otras personas si es una respuesta a su artículo?
¿Y te refieres a publicaciones, no a temas?
Sí, si una publicación es una respuesta o está relacionada con su artículo se determina actualmente por la etiqueta.
Pero también puedo crear un grupo por artículo si eso va a ayudar.
Y, idealmente, tanto las publicaciones como los temas deberían ser editables.
Los grupos son muy ligeros, puedes tener muchos miles sin problemas.
Por otro lado, tener 20.000 categorías será un problema de rendimiento.
10 Me gusta
Las publicaciones no tienen etiquetas, los temas sí.
No entiendo por qué quieres que la gente pueda editar las publicaciones de otros. Puedes hacerlas wikis, pero entonces cualquiera puede editarlas.
O tal vez quieres que el tema del usuario sea una wiki para que cualquiera pueda editarlo.
Simplemente no entiendo cuál es el modelo en el que tiene sentido cambiar las palabras de otra persona.
2 Me gusta
También comencé a cuestionar los méritos que aporta la edición después de considerar varios escenarios. Sin embargo, sería bueno tener un mecanismo para ver si una persona que responde es el autor del artículo al que se relaciona el tema y creo que todavía no es posible con los grupos.
Más explícitamente: digamos que un usuario creó una publicación etiquetando el artículo con el id 5. Si el autor del artículo 5 publica una respuesta a ese tema: La funcionalidad ideal sería indicar de alguna manera (puede ser una insignia, un título, un pequeño texto predeterminado en la parte superior de la publicación) que el usuario que responde es el autor del artículo que se está discutiendo.
Si cada artículo es un tema y asignas el tema OP al autor, es trivial crear una regla CSS para agregar alguna diferenciación visual a las respuestas del OP en sus respuestas posteriores.
1 me gusta
¿Por qué no tener un tema por artículo? Así no hay confusión. No necesitarías etiquetas ni grupos.
Además, parece que estás confundiendo el sentido de tema de Discourse (una colección de publicaciones) y una publicación (un mensaje único de una persona que reside en un tema).
Pero ahora @falco se me ha adelantado…
1 me gusta
@pfaffman @falco Técnicamente, cada artículo es una etiqueta. La razón es que un tema no es suficiente para tener todas las discusiones o preguntas sobre un artículo. Hay muchos aspectos diferentes a discutir y la principal motivación de este foro es tener una única fuente de todas las discusiones que ocurrieron en torno a un artículo. Por lo tanto, cada artículo es una etiqueta y todos los temas creados bajo la etiqueta de un artículo se pueden ver desde la página /tag/:paper_id.
¿Es posible hacer el truco de CSS en este escenario? Puedo crear una base de datos externa que defina la relación entre las etiquetas y sus respectivos “usuarios autores” si es necesario.
1 me gusta
Sí, podrías tener un archivo CSS que se generaría automáticamente a partir del análisis de dicha base de datos.
También podrías hacer todo esto en Discourse utilizando un plugin personalizado. Traería un campo adicional en el serializador de temas para las publicaciones donde el autor de la publicación coincide, lo que luego podría ser aprovechado por la aplicación de front-end.
1 me gusta
Entiendo, soy bastante nuevo en los plugins, pero intentaré ver qué se puede hacer. ¡Muchas gracias por el consejo!
2 Me gusta
Siéntete libre de abrir temas en Dev cuando te quedes atascado.
1 me gusta
Así que entiendes que los temas tienen etiquetas, no las publicaciones. Creo que estás usando la palabra “publicación” cuando quieres decir “tema”.
No creo que hayas respondido a esto. Si no quieres que la gente edite las publicaciones de otras personas, no creo que tengas ningún problema. No puedo imaginar por qué querrías que la gente editara las publicaciones de otras personas, pero si lo haces, convertirlo en una wiki podría ser la solución.
Etiquetar temas que tratan sobre un artículo en particular con una etiqueta del artículo (como un DOI, pero supongo que puede que no haya un DOI en este momento de la vida del artículo) es una gran idea y puedes hacerlo ahora mismo con la API. Además, los usuarios que pueden editar el tema (nivel de confianza 3 y el propietario del tema) pueden agregar la etiqueta; otros podrían marcarla y pedir que se etiquete (pero ¿no sabe quién inició el tema que trata sobre el artículo?).
No está claro para qué necesitas un plugin en este momento.
¿Podrías decir algo sobre dónde se manifestarían los problemas de rendimiento? Es decir, ¿es en páginas específicas o un problema general? Si cada categoría está vinculada a uno o dos grupos, y el usuario promedio solo tiene acceso a 10-20 categorías en total, ¿sigue siendo un problema tener 20.000 categorías?
Para mi caso de uso (hipotético), es permitir que los temas públicos se discutan a través de mensajes privados grupales. Este enfoque podría usarse de algunas maneras diferentes en un intento de generar discusiones públicas productivas en torno a temas polarizadores. Esencialmente, las discusiones podrían gamificarse pidiendo a las personas que se unan a equipos (grupos) relacionados con un tema específico y luego sigan un conjunto de reglas para responder al tema público como equipo.
Estoy preparado para lidiar con los problemas de interfaz de usuario que miles de grupos podrían crear para el personal del sitio. Me doy cuenta de que este es un caso de uso inesperado para los grupos de Discourse, así que lo publico aquí por si acaso hay algún problema de rendimiento obvio que me esté perdiendo.
1 me gusta
Bueno, eso tiene más sentido de lo que imaginaba. 
Creo que hay alguna función de grupo creado por el usuario en preparación, pero sospecho que falta bastante.
1 me gusta
Eso sería genial, pero por ahora se puede hacer con la API.
1 me gusta
Oooh. Estoy empezando a desviarme del tema, pero podrías usar una de esas cosas de API que reciben un webhook por cada nuevo tema y luego crean un grupo para él. No se requiere ningún plugin. No sé por qué no había pensado antes en tener Discourse en ambos lados de uno de esos servicios.
Y GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows llegó a mi escritorio hoy. Parece que podrías hacer que hiciera el trabajo en lugar de pagar por uno de esos servicios. Dudo que tenga soporte para Discourse de inmediato, pero debería ser lo suficientemente fácil como para hacerlo funcionar.
1 me gusta