Thinking through the problem one area Discourse is a bit weak is around defining “dynamic” groups of users.
Give me a group of users that signed up more than 1 month ago
Give me a group of users that posted at least 10 times
And so on.
Badges on the other hand have very rich support for this “dynamic” nature once the fancy SQL is enabled.
Having an “extra” tick box on badges to bridge a badge to a group would add a lot of power. We have no way of assigning permissions to badge holders as it stands cause there is no backing group. Only the trust level badges have this special behavior (which we could port to this new system)
So my proposal here is for:
[ ] mirror badge members in a group
Once this is ticked on a specific badge a “group” would be either automatically created or looked up based on name and the members of the group would be kept in sync as the badge membership changes.
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.
Easiest way to land this would be by using Discourse automation, a special “synchronize badge to group” custom script, should be reasonably easy to build.
