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.
תודה לכל מי שתרם לשרשור הזה. אני רק רוצה לשאול בנימוס האם הבעיה הזו תטופל במהדורה קרובה - או לפחות תוכר כנסיגה ידועה.
כיבוי שמות מאופשרים שובר כרגע פונקציונליות מפתח של מנהל מערכת בצורה שנראית לא מכוונת, וחוסר הבהירות לגבי אם זה נעשה בכוונה או באג מקשה עלינו לתכנן בהתאם. עבור אלה מאיתנו שמריצים אתרי ייצור שבהם שמות משתמשים מועדפים על פני שמות מלאים, הגבלה זו מציגה חיכוך אמיתי והתנהגות בלתי צפויה.
אני מבין שצריך לאזן סדרי עדיפויות, אבל זה יהיה מועיל מאוד לקבל עדכון מהצוות לגבי אם זה נמצא על הכוונת. תודה מראש על כל תובנה שתוכלו לספק.
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.
כן, האמת שאני מופתע שזה לא קיבל יותר תשומת לב. אני מבין שחוששים לעשות PR בלי לדעת אם זה ייבדק
וייתכן שימומש. אם כי אני מתאר לעצמי ש-PR אולי יכול להפוך לתוסף, אבל זה מגביל את האפשרות הזו יותר לאירוח עצמי.
@mdoggydog נראה שהפתרון שלך כאן הוא להחליף את הגדרת ה-enable names בהגדרה שלוקחת רשימה של קבוצות, ושמות של חברים גלויים רק לקבוצות אלה.
שים לב שזה עדיין יצטרך לכבד את ההגדרה display name on posts (וכל הגדרה דומה אחרת שעשויה להתקיים), כך שגם קבוצות מורשות לא יראו את השם בפוסטים אם הגדרה זו מושבתת.
בנוסף, יש עוד כמה דברים שאנחנו צריכים לתקן/לשנות כאן כהשפעות נלוות:
שמות צריכים להיות גלויים תמיד בתצוגת הניהול של פרופיל משתמש. זה יהיה המקרה ללא קשר להגדרות כלשהן.
שמות צריכים להופיע באימיילים רק אם המשתמש נמצא בקבוצה מורשית.
האמור לעיל אמור לתקן את הבעיות הנוכחיות, כמו גם להפוך את התכונה הזו לגמישה ושימושית יותר.
האם זה נשמע כמו מה שאתה מציע כאן? אם כן, נשמח בהחלט להציץ בכל PR שתגיש עם העדכון הזה כלול.
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.
אני מבין שזה עומד לכלול גם תיאום שינויים במאגרי התוספים של Discourse — מה שאומר שרשרת של בקשות משיכה (PR), בסדר הפוך, כדי להבטיח שהבדיקות תמיד יעברו (וכמובן, ש-main תמיד יהיה פונקציונלי).
אני מתאר לעצמי שהרצף ייראה כך (כאשר CORE פירושו “PR ב-discourse/discourse” ו-PLUG פירושו “בקשות משיכה במאגרי תוספים רשמיים”):
אכוף העברת טווח סריאליזציה (לא צפוי שינוי פונקציונלי)
א. CORE יישם בדיקת טווח סריאליזציה, מושבתת כברירת מחדל
ב. PLUG תיקונים להעברת טווח
ג. CORE תיקונים להעברת טווח, והפעלת בדיקת טווח כברירת מחדל
ספק מראש Guardians (מחליף מצייני מקום) במקומות הדרושים עבור שלב 4 (לא צפוי שינוי פונקציונלי)
CORE תיקוני מציין מקום
PLUG תיקוני מציין מקום
יישם Guardian#can_see_full_names? פשוט שתלוי רק ב-enable_names(לא צפוי שינוי פונקציונלי)
CORE הוסף מתודה ל-Guardian
השתמש ב-can_see_full_names? בכל מקום ששם מלא נפלט (החלפת שימוש גולמי ב-enable_names כנדרש) (ייתכן שינוי פונקציונלי)
CORE השתמש במתודת Guardian חדשה
PLUG השתמש במתודת Guardian חדשה
יישם הגדרה של full_names_visible_to_groups(שינוי פונקציונלי)
CORE הוסף הגדרה חדשה לתצורה, ובדוק את ההגדרה במתודת Guardian
(1) ו-(2) מסתכמים בהבטחה ש-Guardians ישמשו באופן עקבי ואמין יותר בכל בסיס הקוד של Discourse.
(3) ו-(4) עוסקים ביצירת הפשטה מדויקת יותר לשליטה מתי שמות מלאים נחשפים על ידי העורף (החלטה על חשיפה בהתאם לכל הקשר ש-Guardian מייצג).
(5) הוא סוף סוף החלק (היחסית טריוויאלי) שבו חשיפת השם המלא מגודרת על ידי חברות בקבוצה.
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
)
)
