I understand from prior discussions in early 2017 that badges do not work for groups that are restricted.
We are looking to see if there is any way around this limitation, a bit of a backstory.
Our group is 99.9% accessible only by those with a role of “Members.” We have a few groups that are open to all for public discussion or help/support. As a paying member group, it would be amazing to be able to recognize the activity within these private groups as of our 1.3+ million posts most of them are inside of those groupings.
Is there a workaround, or configuration that could allow this?
The reason for this is that any badges that reference posts run their queries against the badge_posts table. That table only includes posts that are in categories that are accessible to all users.
Yeah, I can see how that would be a problem. A possible workaround would be to rewrite the badge queries for your site to use the posts table instead of the badge_posts table. This would cause an issue for users who do not have access to your site’s protected categories if they attempted to view the posts that are associated with your user’s badges, but it sounds like this wouldn’t affect many users on your site. Possibly there are other ways this could be dealt with.
Changing the badge queries on your site to use the posts table instead of the badge_posts table would be fairly straightforward. A proper fix for the problem might require a bigger change though. For example, you wouldn’t want badges to be awarded for posts in your staff category, or for any other category where there is a concern about leaking a topic’s title.
I’m wondering if a new Postgres view could be added through a plugin for site’s that have a similar configuration to your site. That view could then be substituted in the badge queries for the badge_posts view.
If that route was an option, could that view include posts that were all public groups. Like we have now plus any group that was visible to a specific group? In our case “Members”
That would be the epic solution for membership groups!
Let’s see what the Discourse engineers think about that kind of approach, or if they have other suggestions. This isn’t the first time that the issue has been reported. It would be good to come up with a general solution for the problem, but a good solution that works for a lot of sites might be more involved than what I’m suggesting.
I’ve been looking at the existing badge queries to get an idea of which queries target posts in the badge_posts table, or use some other method of excluding posts from protected categories from being used.
The following badges query specific posts and will not be awarded for activity in private categories:
Editor
First Flag
First Like
First Link
First Quote
First Share
First Emoji
First Mention
First Onebox
First Reply By Email
Reader
Wiki Editor
Great Share
Good Share
Helpdesk
Nice Share
Welcome
Famous Link
Great Reply
Great Topic
Good Reply
Good Topic
Hot Link
Nice Reply
Nice Topic
Popular Link
The following badges do not query specific posts and will be awarded for activity in private categories:
Licensed
Autobiographer
Certified
New User of the Month
Read Guidelines
Admired
Champion
Crazy in Love
Devotee
Empathetic
Aficionado
Anniversary
Campaigner
Gives Back
Higher Love
Respected
Appreciated
Enthusiast
Out of Love
Promoter
Thank You
Leader
Regular
Basic
Member
Staff
Profile Picture
Something similar to this is already covered by the Appreciated (1 like on 20 posts) and Respected (2 likes on 100 posts) badges. Some variations of these queries could be added. For example, 10 likes on 20 posts. A badge that was granted for super-liked topics could also be a good idea - it would function as the equivalent of the Great Topics badge. For example, it could be awarded when a user has created 10 topics that have received 10 likes.
I’m not sure if it would make sense to add a badge that is awarded for activity on a single post or topic that does not link to the post. For example, an alternate First Like badge could be created with the following sql:
SELECT pa1.user_id, pa1.created_at granted_at
FROM (
SELECT pa.user_id, min(pa.id) id
FROM post_actions pa
JOIN posts p on p.id = pa.post_id
WHERE post_action_type_id = 2
GROUP BY pa.user_id
) x
JOIN post_actions pa1 on pa1.id = x.id
For the query to work, it needs to use the “Update daily” trigger instead of the “When a user acts on a post” query. On the Badges page, users who have been awarded the badge will be shown along with the time that the badge was granted. There will not be a link to the post that the badge was awarded for:
Does this kind of approach make sense for sites that have mostly protected categories? If it does, it could be used for duplicating some of the queries that are currently targeting the badge_posts table.
Thanks for reminding me of this! I’ll start assembling a list of badges that I think could be useful that don’t expose any posts from protected categories.
We started our forum with login required and recently added some public categories, while restricting the existing ones to access from trust_level_0.
So for existing users, nothing about the way they access the forum changed, but all the badges from the list above got revoked. We don’t have a big forum, but from the responses I got from users it’s clear that it feels like the badge system is all broken. With this setup, I practically have to disable it.
I think that it would need to be more clearly communicated somewhere in settings, that existing badges will be revoked, when you opt for restricting categories. For us, that came just out of the blue.
More generally, I don’t understand the priorities. Both category permissions and the badge system are communicated as central features of Discourse. But you can hardly use them together as it is. The advantage of having badges only on generally accessible posts seems to be that other users can see for which post a badge was awarded? To me that doesn’t seem such an important feature in comparison. Why not rather remove these visible links and only reveal related posts to each user on their own badges?
This seems to be related to what came up in another topic about facilitating orientation of community members between open (public) and closed (varying degrees of « private ») spaces, including personal messages.
Dealing with the semi-public nature of the web and semi-overlapping audiences is a major challenge in the online social world. It’s not intuitive. Most communities will grapple with how to make sure people understand how public/private different parts of it are. It might make sense for Discourse to assume this mix of public and private(s) will be the default for most communities and see how it can facilitate navigating it for community members?
I’m new to this conversation, though I think a toggle under Badge Settings would be easiest. Leave it off by default, check it on to query all boards (including private) for engagement badges.
If it’s left open for a hook that a plugin/component could use, one could come in later to give a per-category permission for badges to be counted there.
I think the problem with the badges that are currently only granted on public categories is that they refer to the post in the topic they were granted for, and you would not want that to be public if the topic is private.
