이러한 필드에 민감한 데이터를 사용할 때는 주의가 필요합니다. 필드는 소스에서 찾을 수 없으나, 문제가 발생하면 노출될 수 있습니다. 또한 검색 도구에서 검색 결과가 표시될 수 있습니다.
derek_test(왼쪽)와 anon9(오른쪽)라는 두 명의 사용자가 있습니다. 두 사용자의 프로필에는 모두 ID 및 Company 필드가 입력되어 있지만, 서로에게 보이는 필드는 하나뿐입니다. derek_test는 ID를 볼 수 있고, anon9는 Company를 볼 수 있습니다.
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.
Good callout, I just updated it to account for this. Can confirm that logged-out users don’t see the field.
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
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.”.
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.
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:
Two users, admin and Alex_1
User group L2_verified
User field - Full Name (For all users, all On, only searchable Off)
Both users has names: Alex Admin and Alex
Theme settings:
Include component on these themes (Foundation, Horizon)
Field name: Full Name
Allowed groups: L2_verified
Results:
Both are not members of L2_verified - nobody sees Full Name field (even its own Full Name)
admin is a member of L2_verified - can see Full Name of Alex_1 (and it’s own Full Name)
Alex_1 is a member of L2_verified - cannon see Full Name of itself and of admin
When I granted admin to Alex_1 - it can see both Full Name - itself and admin
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
이 기능을 사용하시는 분들을 위해 참고사항을 공유드립니다. 이 테마 컴포넌트 대신 다른 경로를 선택하게 되었습니다. 검색 시 용어가 노출되는 것을 발견했는데, 이는 중대한 취약점이었습니다. 'Searchable’은 사이트 검색이 아니라 사용자 디렉토리를 가리킨다는 점을 명확히 추가하겠습니다.