I gave some background on the use-case in Restrict exposure of full name to certain groups. We are using Discourse to facilitate discussion about local public schooling; the target userbase is primarily parents and other local community members. We want to strike a balance:
On the one hand, make the site open to anonymous browsing (so that search engines can index it, so it is accessible even to non-members, so it is open/transparent as a matter of principle, …)
On the other hand, avoid unnecessarily making personally-identifiable information available to crawlers and drive-by non-members — we want to let people share their names within the community and want to address the cagey-ness a lot of people have in doing so.
Originally, it looked like disabling “Display name on posts” and enabling “Hide user profiles from public” would take care of blocking name-leaks to anonymous users — but then we realized that it doesn’t. (And we already promised people via TOS and FAQ that we would. )
Denying full-name access to just anonymous users would get the job done. But, since it is really just as easy to key the access to group-membership, I figure might-as-well do that — which opens up the possibility, on our site, to restrict access to >=TL1, which is even better. (Currently, we require an invite to sign-up, but we want to get rid of that.)
In looking into this issue/topic, I’ve seen other mentions of same or similar asks, e.g., “we only want so-and-so group to be able to see names”… so this would take care of those uses, too.
A question for you (which you might even consider a product question!):
Is the enable_names setting intended to mean “Do not show full names to users.” or rather “This site does not use full-names, period.” ?
I get the feeling (from the code itself, and from topics/issues like this one) that there is an underlying lack of clarity on this point — and some folks have understood it one way, and some the other.
Agree. Admins should be able to have access to the Full Name without having to turn on and off the toggle. There are particularly important reasons (at least for our forum) to hide real names.
Thanks to everyone who has contributed to this thread. I just want to respectfully ask if this issue is going to be addressed in an upcoming release—or at least acknowledged as a known regression.
Disabling enable names currently breaks key admin functionality in a way that seems unintended, and the lack of clarity about whether this is by design or a bug is making it difficult for us to plan around. For those of us running production sites where usernames are preferred over full names, this limitation introduces real friction and unexpected behavior.
I understand priorities have to be balanced, but it would be incredibly helpful to get an update from the team about whether this is on the radar. Thanks in advance for any insight you can provide.
Hey, @tobiaseigen, any engineering input on this? (It’s been 3 months — but I also was busy with other things and lost track of this myself, so I can’t complain.)
I could start submitting pull request(s) this week to make the conversation more concrete — but I’m leery of having them sit unreviewed, and I could also use some feedback on some aspects of my approach.
Yeah tbh I am surprised this hasn’t had more attention. I sc understand being Leary to to do a pr without knowing if it will be reviewed.& Potentially implemented.
Though a pr I imagine could maybe become a plugin but the. Itimits this option more to self hosted.
@mdoggydog It looks like your solution here is to replace the enable names setting with one that takes a list of groups, and member’s names are only visible to those groups.
Note that this would still need to respect the display name on posts setting (and any other similar ones that may exist), so even allowed groups don’t see the name on posts if that setting is disabled.
Additionally, some other things we need to fix/change here as knock-on effects:
Names should always be visible in the admin view of a user profile. This will be the case regardless of any settings.
Names should only show in emails if the user is in an allowed group.
The above should fix the current issues, as well as make this feature more flexible and useful.
Does that sound like what you’re proposing here? If so, we would definitely be happy to have a look at any PR you submit with this update included.
The code I have written does not remove the enable names setting,[1] but adds to it:
Add a full_names_visible_to_groups setting (which includes admins and moderators as mandatory values).
Add a can_see_full_names? method to Guardian, which performs an “and” of enable_names and the group membership in full_names_visible_to_groups.
Use this new method in all the appropriate places where a full name is exposed/emitted by the server.
1 and 2 were easy. 3 is more complicated, and I know I hit some snags that I was not sure how to resolve without getting advice/guidance. I need to go back and review my code and notes in depth. (It has been 2+ months since I last immersed myself in this. )
(If I recall, display name on posts and the like are client-side settings, that affect the presentation of data received from the server. In other words, a restriction on top of whatever the server emits.)
I believe (1) is taken care of if enable_names is true, which will probably be what almost everyone wants once the new per-group setting is available.[2]
I think I encountered and dealt with (2) — mostly.[3]
I recall some other cases where full names are being leaked.[4]
Anyhow, I will go review notes and try to submit PR’s this week, and dredge up the open-questions/loose-ends in the process.
…for a number of reasons, among them: (a) I wasn’t sure what the actual intent of the setting is (see my question in an earlier post above), and (b) leaving it in there provides a safer incremental upgrade path. ↩︎
…if one takes that stance that enable_names = false means “This site does not use full names in any way.” ↩︎
E.g., when an invite email is sent to some address (obviously not associated with a user, otherwise they would need no invite), does the email include the inviter’s full name or not? ↩︎
E.g., oneboxer.rb, when oneboxing a local user, writes the full name into the cooked post content, which makes it visible to everyone and anyone, forever. ↩︎
This PR is a prerequisite for the subsequent one(s), ensuring that Guardian instances actually get passed from one serializer to the next. Details are in the PR/commit-message. The conversation about this PR might as well get started while I prepare the next one.
My Mini GitHub Account Adventure
…well, it was there until I typed the URL into the edit box here …and then my entire account was suddenly suspended.
I have filed a reinstatement request, and will update this when I have an update.
13 hours later, I received email that said, basically, “Sometimes this happens; all good now.” Very Kafkaesque. My account was disappeared from the site — to the point that posts that I had made in Issues/PR’s years ago were vanished, leaving behind mysterious one-sided conversations, with a few ghostly blockquotes as the only evidence that someone else (me) had been there.
This seems horrifyingly heavy-handed, not just for the suspended account, but also for all the projects having chunks of their history quietly stripped away.
I am realizing that this is going to involve coordinating changes in the discourse plugin repos, too — which means a chain of PR’s, in kind of an inside-out order, to ensure that tests always pass (and, of course, that main is always functional).
I imagine the sequence would look like this (where CORE means “PR in discourse/discourse” and PLUG means “PR(s) in official plugin repos”):
Enforce serializer scope forwarding (no functional change expected)
a. CORE Implement serializer scope checking, disabled by default
b. PLUG Fixes for scope forwarding
c. CORE Fixes for scope forwarding, and enable scope checking by default
Preemptively provide Guardians (replacing placeholders) in the places necessary for Phase 4 (no functional change expected)
CORE Placeholder fixes
PLUG Placeholder fixes
Implement simple Guardian#can_see_full_names? that only depends on enable_names(no functional change expected)
CORE Add method to Guardian
Use can_see_full_names? wherever full-name is emitted (replacing bare use of enable_names as appropriate) (might have functional change)
CORE Add new setting to config, and check the setting in the Guardian method
(1) and (2) boil down to ensuring that Guardians are used more consistently and reliably throughout the Discourse codebase.
(3) and (4) are about instituting a more precise abstraction for controlling when full-names are exposed by the backend (deciding on exposure depending on whatever context the Guardian represents).
(5) is finally the (relatively trivial) part where full-name exposure is gated by group-membership.
Thanks! I’ve looped an engineer in here to have a look. It sounds like you’re on the right track here, but an engineer will be able to provide more informed feedback
I am sorry, but I have to reject this PR. That change is too complex and hard to maintain. The main reasons are:
Scope is not always required and should not be enforced;
Changing and later maintaining it in all the places, like plugins, would be an enormous amount of work;
PlaceholderGuarian is not solving the problem but adding a fake scope (with the intention to fix later);
Most of the time, serialisation should be happening in the controller, and the scope will be added automatically.
Displaying a username or full name based on group is quite tricky. Instead of trying to merge it into core Discourse, can we start by creating a plugin? If your community is small, this is how it can work:
Set SiteSetting.enable_names to false to always use username;
Define an endpoint that would return a map of username → full name for TL3 users;
I think there is still a fundamental misunderstanding/disagreement about just what the enable_names setting is supposed to do, which boils down to this question:
Is the enable_names setting intended to mean
“Do not show full names publicly.”,
“This site does not use full-names, period.”
I think some people on this topic think it does (1), and others think it does (2). My impression is the latter, that enable_names decides whether or not the site uses full-names at all.
Keep in mind, when enable_names is turned off:
The sign-up dialog does not offer the full-name field.
Users do not see the full-name field on their own account preferences page; users never see their own full-name anywhere.
I do not understand the use case for a site in which admins, and only admins, are the only people that even know that a full-name field exists on the system. My lack of imagination makes me dubious that anyone here actually wants that. If anyone does want this, please enlighten me!
(I think there is also some misunderstanding about what my draft PR is trying to accomplish, and how, and why — but I wanted to address the “What does enable_names actually do?” question first.)
Yes, I can name numerous examples. Often the business owning the community has the legal right (and/or need) to know the names of their clients but privacy laws forbid them to publish those names to third parties. Pretty much the same thing as why using CC in a mass email is a no-no and you’re supposed to use BCC.
Well, this started out as a pretty simple bug report where it simply misbehaved. And then we all got into a discussion about what it was supposed to do, that also caused a lot of confusion and extra discussion. Which is fine, but would have been better off in a Feature topic.
It’s #1. The description for the setting says:
Show the user’s full name on their profile, user card, and emails. Disable to hide full name everywhere.
The fact that the full name is hidden implies that it does exist, and admins can see hidden things.
There is also display_name_on_posts, full_name_requirement and display_name_on_email_from.
If you want #2 I guess it would make more sense to build upon full_name_requirement and add an option ‘Never’ there.
(And yes, I agree about that enable_names should be called differently but renaming settings is never fun). And I also agree that
Will this fix restore original function? Ie admin and the user can see their full name? Just seems this change initially has caused a lot of issues vs the original function. Even full moderator should have an option to see real name via a setting as some case uses this could be desired/needed.
After the team pushed this change any users who had entered real name became blank.
This setting imho should have been separated into 2 settings with clear definitions. With the newer feature to disable names being a new setting to turn off real names.
I am fortunate I have a small community. Imagine a site with thousands of members where their real name blanked out
)
)
