Hidden User Fields

[putty (Derek Putnam)]

	Summary	Create user fields that are only visible to specified groups
	Repository	discourse-hidden-user-fields
	Install Guide	How to install a theme or theme component
	New to Discourse Themes?	Beginner’s guide to using Discourse Themes

Install this theme component

Detailed Description

Use caution with sensitive data in these fields. Fields are not found in the source, but could be visible if something breaks

I have two users, derek_test (left) and anon9 (right). ID & Company fields are both populated in their profiles, but only one is visible to the other. derek_test can see ID and anon9 can see Company.

User profiles

User Cards

Search

In this case, anon9 (right) can see the company and search for Acme.

---

Settings

• Field Name: insert name of custom user field (one per object)
• Allowed Groups: Select allowed groups from the list

Prerequisites

This leverages Custom User Fields. These settings dictate where the fields will be visible:

Revisit these settings once the fields are populated or create permissions ahead of time, so that these fields are never exposed.

[Moin]

What do users who are not logged in see? So, if the field is only visible to admins, then I would expect that users would not be able to see it even after logging out, correct?

Is there a reason why you chose the text field for the group setting instead of a group_list? It’s a bit more convenient for entering groups because you can select them instead of typing the name. However, it works with the ID, so you have to change the code a little. But it still works even if you rename the group.

settings.yml

[putty (Derek Putnam)]

@Moin

What do users who are not logged in see? So, if the field is only visible to admins, then I would expect that users would not be able to see it even after logging out, correct?

Good callout, I just updated it to account for this. Can confirm that logged-out users don’t see the field.

@Moin

Is there a reason why you chose the text field for the group setting instead of a group_list?

I’ll be honest and say that I did this with Claude Code, but it said that the list_type: group is not available in an object editor—only as a top-level setting.

So it would have to be something like this, but a fixed number of available fields

[Moin]

@putty

but it said that the list_type: group is not available in an object editor—only as a top-level setting.

That’s interesting. Based on the documentation I expected it to support something like that too

@Discourse

Currently the following types are supported:

• string: Value of property is stored as a string.
• integer: Value of property is stored as an integer.
• …
• categories: Value of property is an array of valid category ids.
• groups: Value of property is an array of valid group ids.
• tags: Value of property is an array of valid tag names.

[putty (Derek Putnam)]

Thank you for pointing that out! I was able to modify the group settings based on that documentation!

I’ll update the details above to reflect the change.

[putty (Derek Putnam)]

Huh.. Although the settings in the object editor did accept the list_type:group, I couldn’t get past an error:

I tried a few different transformations but couldn’t get through. The verdict is that “The groups type in object schemas is documented but the UI is not implemented in the frontend.”.

[Moin]

I saw that error too, but after I used the reset button to reset the whole object setting, the error didn’t come back

So all good now

Maybe it didn’t like changing the setting type on an existing configuration

[Heliosurge (Dan DeMontmorency)]

I can see this being very useful!

[AirVetra (Alexey Goloviznin)]

HI, @putty !

Have some problems with it:

I need to hide user fields from every user not in User group - seems just the case?

1. If user itself are not in this group - it also cannot see this fields at its own account - is it ok?
2. Other users will continue not seeing the fields if they are not Admin or Moderator!
3. BTW, Moderator and Admin should be also in this Group to see the Fileds, hidden by this Theme.

Could you help with it?

[putty (Derek Putnam)]

Hi Alexey,
Can you elaborate? I don’t see the problem. It currently has 1 & 2. Is your request to hide fields from mods/admins also? FWIW, admins would have to create the field initially.

[AirVetra (Alexey Goloviznin)]

Hi, thanks!

Just tested it again on my local clear latest github repo and on hosted solution with the latest build - only Admin category is affected and can see the Hidden field if he/she is a member of a group that allowed to see this field. Even Moderator access (as i thought before doesn’t work)

The case:

1. Two users, admin and Alex_1
2. User group L2_verified
3. User field - Full Name (For all users, all On, only searchable Off)
4. Both users has names: Alex Admin and Alex
5. Theme settings:
   Include component on these themes (Foundation, Horizon)
   Field name: Full Name
   Allowed groups: L2_verified

Results:

1. Both are not members of L2_verified - nobody sees Full Name field (even its own Full Name)
2. admin is a member of L2_verified - can see Full Name of Alex_1 (and it’s own Full Name)
3. Alex_1 is a member of L2_verified - cannon see Full Name of itself and of admin
4. When I granted admin to Alex_1 - it can see both Full Name - itself and admin

[putty (Derek Putnam)]

So… It sounds like we’re good? haha

[AirVetra (Alexey Goloviznin)]

My Antigravity with Gemini 3 Pro High found the root cause:

Root Cause Identified: The group

L2_verified

exists and

Alex_1

is a member,BUTthe group’sVisibility Level is set to 4(Staff/Owners only).

Because of this restrictive setting, Discourse does not tell the browser that

Alex_1

is a member of this group (unless he is also Staff/Admin). Therefore, the Theme Component checks the list, doesn’t find

L2_verified

, and keeps the field hidden.

Fix:

1. Go to Groups → L2_verified → Manage → Interaction.

2. Change Who can see this group? to “Members” or “Everyone”.

3. Save.

4. Refresh as

   Alex_1
   

   (non-admin). It should now work!

But it’s not a workaround for now - most of our groups are hidden from everyone:(

[AirVetra (Alexey Goloviznin)]

Hi @dereklputnam,

Thank you for this great component! It’s a fantastic foundation for managing user privacy on Discourse.

I’ve developed a specialized bidirectional (reciprocal) visibility fork based on your work. In our professional community, we needed a “Mutual Trust” model where verified members can see each other’s real names/business data, but remain completely anonymous to the general public or unverified users.

Key features of this fork:

• Reciprocal Logic: A field is revealed only if both the viewer and the profile owner belong to the authorized group.

• Staff Oversight: Admins and moderators retain full visibility for safety and moderation purposes.

• Self-Visibility: Users can always see their own hidden fields, even if they are not yet part of the authorized group, so they can manage their own profile.

• Peer-to-Peer Privacy: It ensures that even verified users don’t reveal their identity to someone who hasn’t undergone the same level of verification.

Roadmap: In future updates, I plan to add granular group settings to define exactly which groups can see and be seen (e.g., allowing Group A to see Group B, but not vice versa).

I’m currently polishing the documentation and plan to publish this as a standalone “Advanced Privacy” variant in a separate topic once I gain full access to the Theme Components category.

In the meantime, if anyone needs this bidirectional logic, you can check it out here: GitHub: https://github.com/AirVetra/discourse-hidden-user-fields-bidirectional

Thanks again for the inspiration!