Do not display the usernames that hold a specific badge

[Richie (Richie Rich)]

Is there a way to hide the list of users that have a specific badge?

I’ve looked at Don't list members having the same badges and Hide badge user list? but they don’t quite fit our use case (or more likely, our edge case).

Badges are hugely popular in our community, they’re a fantastic resource for engagement.

We have some premium categories on our Discourse which are only available to subscribers / paying-members and we would like to reward those paying members with a gold badge for their profile, lets call it “Extra Special Member” in this example.

The number of paying members we have is a commercially sensitive number.

That number would be leaked to anyone holding the Extra Special Member badge, even though it is hidden on the badge page, they could simply click on their own badge and then see all the other members that also hold that badge.

Is there a way to prevent people seeing who else holds just one specific badge?

[Stephen]

Could you not use flair instead?

[Richie (Richie Rich)]

Hmmmm

Quite possibly…

Does this warning carry a risk of leaking sensitive member-numbers?

Since this is a primary group, the name ‘hidden_group_test_2’ will be used in CSS classes which can be viewed by anyone.

Excuse the loud colours, it’s just for testing:

[Richie (Richie Rich)]

@Richie

Does this warning carry a risk of leaking sensitive member-numbers?

I have no objections to the hidden group name being leaked, as long as the members list / count isn’t.

[Richie (Richie Rich)]

@Stephen

Could you not use flair instead?

I’ve performed a few tests but I’m not sure this is ideal for our use case either.

The flair (from our hidden group) gets applied to the user, but the moment they join any of our other groups their flair is replaced with that of the group they just joined.

On their profile, they are then only able to chose a flair of a public group, they completely lose access to their special member flair and can’t re-apply it

[Stephen]

Do you have this set on the other groups:

It’s under ‘Effects’ on Manage/Membership for each of the groups.

If it’s set on that group and no others then it shouldn’t override.

The primary group will determine the default flair and title for the user.

[Richie (Richie Rich)]

Yes, it’s set on all our groups, so they get the flair for the group they just joined.

[Richie (Richie Rich)]

@Richie

Is there a way to prevent people seeing who else holds just one specific badge?

Other thoughts were along the lines of forcing a title on all users, of “Guest” for example, but that could just be changed by them to any of the badge-titles they hold. I don’t think I can prevent people from changing their Title.

I’m looking for a way for guests and members to identify each other as such (ie. a badge) but without leaking the number of Extra Special Members that we have.

Would there be any other innovative solutions or workarounds?

Could I do something clever with “User Fields”?

Maybe create a user field called “Status”, have it visible on their profile, but not editable by them. Could I then update this “status” user field automatically by an API call? (we fire an api call to add them to a Group)

[Richie (Richie Rich)]

I might be on to something here:

@Richie

Maybe create a user field called “Status”, have it visible on their profile, but not editable by them.

I’ve created a user field called “Member”, and I do not let them edit it:

If I edit one user to test it with, I can see “Member: Yes” on their profile:

This is probably the decider though:

@Richie

Could I then update this “status” user field automatically by an API call?

How would I go about doing this?

I have an existing API calls that is made already when someone becomes a member, I fire an API call to Discourse to add them to a group. Could I also fire a second API call to update that User Field?

[Canapin (Coin-coin le Canapin)]

@Richie

Could I also fire a second API call to update that User Field?

Certainly

Each time you do any action in Discourse, you can check the network tab of your browser dev tools to see the query that was made.

For example, here I save the profile of a user:

You see the request URL, mentioning the username, and the type of request (PUT).
On the Payload tab, you see the relevant data:

The custom fields are listed as user_fields[X] where X is the number of the custom field.

---

Edit: I saw that you figured it out on dev, so, just to crosslink…

Updating Custom User Field through the API

I’ve been trying to reverse engineer the updating of a user_field value. I did this by following the steps in Reverse engineer the Discourse API, I edited a test user and made a note of what was occurring in the network tab of the browser. I can see that I need to PUT to this url: https://example.com/u/my-username-here.json Where I got a bit confused was by not seeing a json payload but instead it’s some formdata. The payload was: user_fields%5B1%5D=some+dji%2C+some+Autel&user_fields%5B5…