En réfléchissant au problème, l’un des domaines où Discourse est un peu faible concerne la définition de groupes d’utilisateurs « dynamiques ».
Donnez-moi un groupe d’utilisateurs inscrits il y a plus d’un mois
Donnez-moi un groupe d’utilisateurs ayant publié au moins 10 fois
Et ainsi de suite.
Les badges, en revanche, offrent un support très riche pour cette nature « dynamique » une fois le SQL avancé activé.
Ajouter une case à cocher « supplémentaire » sur les badges pour lier un badge à un groupe ajouterait beaucoup de puissance. Nous n’avons actuellement aucun moyen d’attribuer des permissions aux détenteurs de badges car il n’existe pas de groupe sous-jacent. Seuls les badges de niveau de confiance ont ce comportement spécial (que nous pourrions porter vers ce nouveau système).
Ma proposition est donc la suivante :
[ ] refléter les membres du badge dans un groupe
Une fois cette case cochée sur un badge spécifique, un « groupe » serait soit automatiquement créé, soit recherché en fonction du nom, et les membres du groupe seraient maintenus synchronisés au fur et à mesure que l’appartenance au badge change.
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.
La façon la plus simple d’y parvenir serait d’utiliser l’automatisation Discourse, un script personnalisé spécial “synchroniser le badge avec le groupe”, il devrait être raisonnablement facile à construire.
