Campos de Usuário Ocultos

[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: List allowed group(s), separated by a comma

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