Badges & Private Communities

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?

4 Likes

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.

7 Likes

Honestly for our purposes I think that would be totally acceptable.

Is this something easy? Or would it be problematic in the long term.

1 Like

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.

4 Likes

Ok I’m liking this theory.

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!

2 Likes

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.

4 Likes

Not a fan of swapping out the view.

My recommendation here @Mitchelsellers is to start small. Award the badges without recognizing specific posts.

[made twenty super liked posts as a member] (title TBD) is a good place to start.

Basically come up with a custom way of recognition with custom queries.

Adding permission checks throughout the places where we link badges to posts is tricky, recommend against taking this path.

Start small and easy.

5 Likes

I think that Would be totally acceptable for us as well.

Any good tips on doing this?

1 Like

I guess step 0 here, is sketching out in English which badges you would like, names of the badges and conceptual definition.

3 Likes

Ok, we will get working on this!

1 Like

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.

3 Likes

I think this is a great step!

I just wanted to circle back on this one.

ANy thoughts on the implementation of this kind of thing?

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.

2 Likes

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?

1 Like