Al analizar el problema, una de las áreas en las que Discourse es un poco débil es en la definición de grupos de usuarios “dinámicos”.
Dame un grupo de usuarios que se registraron hace más de 1 mes
Dame un grupo de usuarios que publicaron al menos 10 veces
Y así sucesivamente.
Por otro lado, las insignias tienen un soporte muy rico para esta naturaleza “dinámica” una vez que se habilita el SQL avanzado.
Tener una casilla de verificación “extra” en las insignias para vincular una insignia a un grupo añadiría mucha potencia. Actualmente, no tenemos forma de asignar permisos a los titulares de insignias porque no hay un grupo subyacente. Solo las insignias de nivel de confianza tienen este comportamiento especial (que podríamos portar a este nuevo sistema).
Así que mi propuesta aquí es:
[ ] reflejar los miembros de la insignia en un grupo
Una vez que se marque esta opción en una insignia específica, se crearía automáticamente un “grupo” o se buscaría uno basado en el nombre, y los miembros del grupo se mantendrían sincronizados a medida que cambie la membresía de la insignia.
Because the group membership management UI is so rich these days, changes should at least attempt to flow in the opposite direction as well (e.g. approving a Request to Join turns into a badge grant from the group manager; which wouldn’t normally happen as they aren’t staff).
I feel like this has massive overlap with trust levels; it’s building a parallel system for.. well, I’m not sure why. In the quote you posted, that is literally the reason we have trust levels in the first place. So tying content unlock to
trust level 1 (a tiny bit of reading)
trust level 2 (a fair bit more reading)
should cover this scenario.
There are many many things I’d rather we work on than this.
I definitely do not see this as an urgent change, we lock out badge sql anyway out-of-the-box. However I do see this as something I would like to get to eventually.
It is a simple generalization of the “automatic group” system that now exists.
This does simplify workflows as well, you can grant a badge to a user and then you do not need to go to the group and also grant membership. For example: “Customer champion” badge that grants access to “champions” group and “champion discussion” category on the site. Having the bridge also means you only need to remove membership in 1 spot to have both badge and group change.
Nothing urgent to change here, its just that there are tons of parallels between groups and badges so having a bridge helps get automatic feature parity on both sides.
I know that just tying this up to the a badge re-uses a bunch of code, and simplifies a lot, but ideally this would be an option in the Groups UI, to have an option query that returns the user_id of members.
When you tie this to SSO and custom user fields, you get a very powerful system, where you can manage groups using queries on those custom fields + all the info Discourse already have.
Bueno, tal vez podría darte suficiente código de café para que puedas ajustarlo tú mismo. Estoy bastante ocupado ahora mismo, pero veré qué puedo hacer.
EDITO: Bueno, no va a funcionar como pensaba. Me tomará algún tiempo averiguar cómo proceder.
La forma más sencilla de conseguirlo sería utilizando la automatización de Discourse, un script personalizado especial de “sincronizar insignia con grupo”, que debería ser razonablemente fácil de construir.
