# ‘이름 사용’을 비활성화하면 관리자 동작이 이상해짐
**URL:** https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912
**Category:** Bug
**Created:** [1월 17, 2024, 7:44오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912 "2024-01-17T07:44:29Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [2월 26, 2025, 8:09오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/29 "2025-02-26T20:09:26Z")
> [@tobiaseigen](#):
>
> 왜 일부 그룹에게는 실명(전체 이름) 접근 권한을 주면서 다른 그룹에게는 주지 않으려는 건가요? 사용 사례를 좀 더 자세히 설명해 주실 수 있을까요?
[Restrict exposure of full name to certain groups](https://meta.discourse.org/t/restrict-exposure-of-full-name-to-certain-groups/348873) 에서 사용 사례에 대한 배경을 설명해 두었습니다. 우리는 Discourse를 지역 공립학교에 대한 토론을 촉진하는 데 사용하고 있으며, 주요 대상 사용자는 학부모와 기타 지역 커뮤니티 구성원입니다. 우리는 다음과 같은 균형을 맞추고 싶습니다:
- 한편으로는 사이트를 익명 브라우징에 개방하여 검색 엔진이 인덱싱할 수 있도록 하고, 비회원도 접근할 수 있게 하며, 원칙적으로 공개적이고 투명하게 유지하는 것입니다.
- 다른 한편으로는 크롤러와 일회성 비회원에게 신원 식별 정보를 불필요하게 노출하는 것을 방지하는 것입니다. 우리는 커뮤니티 내에서 사람들이 이름을 공유할 수 있도록 하고, 많은 사람들이 이를 할 때 느끼는 경계심을 해소하고 싶습니다.
처음에는 “게시물에 표시 이름(Display name on posts)”을 비활성화하고 “공개에서 사용자 프로필 숨기기(Hide user profiles from public)”를 활성화하면匿名用户에게 이름이 노출되는 것을 차단할 수 있을 것 같았습니다. 하지만 그러지 않다는 것을 깨달았습니다. (이미 우리는 이용약관(TOS)과 FAQ를 통해 그렇게 하겠다고 약속했습니다. 🤥)
단순히匿名用户에게만 전체 이름 접근을 거부하는 것만으로도 목적을 달성할 수 있습니다. 하지만 그룹 멤버십에 따라 접근 권한을 설정하는 것이 사실상 동일한 노력을 요하므로, 그렇게 하는 것이 낫다고 생각합니다. 이는 우리 사이트에서 \>=TL1 이상의 접근 권한을 제한하는 가능성을 열어주며, 이는 더 좋습니다. (현재는 가입 시 초대장이 필요하지만, 이를 없애고 싶습니다.)
이 문제/주제를 조사하면서 "특정 그룹만 이름을 볼 수 있기를 원한다"와 같은 유사한 요청을 여러 번 보았습니다. 따라서 이 기능은 그러한 사용 사례도 처리할 수 있습니다.
여러분에게 드리는 질문입니다(제품 관련 질문으로 간주하셔도 됩니다!):
- `enable_names` 설정은 _“사용자에게 전체 이름을 표시하지 마세요.”_ 라는 의미인가요, 아니면 _“이 사이트는 애초에 전체 이름을 사용하지 않습니다.”_ 라는 의미인가요?
(코드 자체와 이 주제/이슈와 같은 것들로부터) 이점에 대해 근본적인 명확성 부족이 있다는 느낌을 받습니다 — 어떤 분들은 한 가지 방식으로, 어떤 분들은 다른 방식으로 이해하고 있습니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [4월 29, 2025, 9:47오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/30 "2025-04-29T21:47:11Z")
> [@tobiaseigen](#):
>
> `enable_names` 사이트 설정이 비활성화되어 있더라도, 관리자가 사용자의 전체 이름을 보고 편집할 수 있도록 항상 허용
이 부분에 대한 진행 상황은 어떤가요? 이 문제는 가장 쉽게 해결할 수 있으면서도 가장 긍정적인 영향을 미칠 수 있는 것 같습니다.
---
### Author:  [@chrismalone](https://meta.discourse.org/u/chrismalone)
#### Post date: [4월 29, 2025, 10:04오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/31 "2025-04-29T22:04:14Z")
동의합니다. 관리자는 토글을 켰다 껐다 할 필요 없이 전체 이름에 접근할 수 있어야 합니다. 실제 이름을 숨겨야 할 중요한 이유가 특히 있습니다(최소 우리 포럼의 경우).
---
### Author:  [@ked](https://meta.discourse.org/u/ked)
#### Post date: [4월 30, 2025, 1:04오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/32 "2025-04-30T01:04:10Z")
이 주제에서 진전이 이루어진다면 정말 감사하겠습니다. 현재 바로, 그리고 지속적으로 필요한 부분입니다.
---
### Author:  [@chrismalone](https://meta.discourse.org/u/chrismalone)
#### Post date: [5월 27, 2025, 3:24오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/33 "2025-05-27T15:24:33Z")
이 스레드에 기여해 주신 모든 분께 감사드립니다. 이 문제가 향후 릴리스에서 해결될지, 아니면 최소한 알려진 회귀 문제로 인정될지 정중히 여쭤보고 싶습니다.
현재 enable names를 비활성화하면 의도하지 않은 방식으로 주요 관리자 기능이 중단됩니다. 또한 이것이 의도된 설계인지 버그인지에 대한 명확한 설명이 없어 대응 계획을 세우기 어렵습니다. 사용자 이름이 전체 이름보다 선호되는 프로덕션 사이트를 운영 중인 우리에게 이 제한은 실질적인 마찰과 예상치 못한 동작을 초래합니다.
우선순위를 고려해야 한다는 점은 이해하지만, 팀에서 이 문제가 인지되고 있는지 여부에 대한 업데이트를 주신다면 큰 도움이 될 것입니다. 미리 감사드리며, 가능한 한 많은 통찰을 주시면 감사하겠습니다.
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [5월 27, 2025, 4:27오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/34 "2025-05-27T16:27:41Z")
> [@tobiaseigen](#):
>
> 귀하의 구현은 나쁘지 않지만, 해당 팀의 엔지니어가 여기에 응답할 기회를 줄 수 있도록 잠시 기다려 주시는 것이 어떨까요.
@tobiaseigen, 이 문제에 대해 엔지니어링 측면의 의견이 있을까요? (3개월이 지났지만, 저도 다른 일에 바빠서 이 문제를 놓치고 있었기 때문에 불평할 입장은 아닙니다.)
이번 주부터 대화가 더 구체적이 되도록 풀 리퀘스트를 제출하기 시작할 수 있습니다 — 하지만 리뷰되지 않은 채로 방치되는 것이 꺼려지며, 제 접근 방식의 일부 측면에 대한 피드백도 필요할 것 같습니다.
수정: 명확히 하자면, 저는 [Restrict exposure of full name to certain groups - #2 by mdoggydog](https://meta.discourse.org/t/restrict-exposure-of-full-name-to-certain-groups/348873/2) (이것은 `enable names`를 활성화하면서 누가 전체 이름을 볼 수 있는지를 제어할 수 있게 해주는 것)의 구현에 대한 풀 리퀘스트를 이야기하고 있습니다.
---
### Author:  [@ked](https://meta.discourse.org/u/ked)
#### Post date: [5월 27, 2025, 5:02오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/35 "2025-05-27T17:02:59Z")
@RGJ @chrismalone 그리고 @mdoggydog, 이 문제에 대한 의견 주셔서 정말 감사드립니다. 아직 이 수정이 시급하며, 문제를 해결하기 위해 노력해 주시는 모든 분들에게 감사드립니다.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [5월 27, 2025, 7:39오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/36 "2025-05-27T19:39:42Z")
솔직히 말해서, 이게 더 큰 주목을 받지 못한 게 좀 놀라워요. 리뷰가 될지, 잠재적으로 구현될지 모르는 상태에서 PR을 올리는 것에 대해 신중하게 생각하는 마음은 이해해요.
다만, PR이 플러그인으로 전환될 수도 있겠지만, 그렇게 되면 이 옵션이 셀프호스팅에 더 많이 제한될 것 같아요.
---
### Author:  [@hugh](https://meta.discourse.org/u/hugh)
#### Post date: [5월 28, 2025, 2:12오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/39 "2025-05-28T02:12:43Z")
@mdoggydog 여기서 제시한 해결책은 `enable names` 설정을 그룹 목록을 받는 설정으로 대체하고, 멤버의 이름은 해당 그룹에만 표시되도록 하는 것인 것 같습니다.
다만, 이 경우에도 `display name on posts` 설정(그리고 존재할 수 있는 기타 유사한 설정들)을 준수해야 하므로, 해당 설정이 비활성화된 상태에서는 허용된 그룹의 사용자도 게시물에서 이름을 볼 수 없어야 합니다.
추가로, 이로 인해 수정/변경해야 할 다른 사항들도 있습니다:
1. 사용자 프로필의 관리자 뷰에서는 설정과 관계없이 항상 이름이 표시되어야 합니다.
2. 이메일에서는 사용자가 허용된 그룹에 속해 있을 때만 이름이 표시되어야 합니다.
위 내용들은 현재 문제를 해결할 뿐만 아니라 이 기능을 더 유연하고 유용하게 만들어 줄 것입니다.
이것이 여기서 제안하신 내용과 일치하나요? 그렇다면 이 업데이트를 포함해 PR을 제출해 주시면 기꺼이 검토해 드리겠습니다.
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [5월 28, 2025, 3:57오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/40 "2025-05-28T03:57:03Z")
> [@hugh](#):
>
> 여기서 당신의 해결책은 `enable names` 설정을 그룹 목록을 받는 설정으로 대체하고, 멤버의 이름은 해당 그룹에만 보이도록 하는 것인 것 같습니다.
제가 작성한 코드는 `enable names` 설정을 제거하지 않고,\[1\] 다음과 같이 추가합니다:
1. `full_names_visible_to_groups` 설정을 추가합니다. (이 설정에는 `admins`와 `moderators`가 필수 값으로 포함됩니다.)
2. `Guardian`에 `can_see_full_names?` 메서드를 추가하여, `enable_names`와 `full_names_visible_to_groups` 내의 그룹 멤버십 간의 “and” 연산을 수행합니다.
3. 서버가 전체 이름을 노출/출력하는 모든 적절한 장소에서 이 새로운 메서드를 사용합니다.
1번과 2번은 쉬웠습니다. 3번은 더 복잡하며, 조언/가이드 없이 해결할 수 있는지 확신이 서지 않는 몇 가지 어려움에 부딪혔습니다. 제 코드와 메모를 다시 자세히 검토해야 합니다. (마지막으로 이 주제에 몰두한 지 2개월이 지났습니다. 🙈)
> [@hugh](#):
>
> 참고로, 이는 여전히 `display name on posts` 설정(그리고 존재할 수 있는 기타 유사한 설정들)을 존중해야 합니다. 따라서 해당 설정이 비활성화된 경우, 허용된 그룹도 게시물에서 이름을 볼 수 없습니다.
(기억이 맞다면, `display name on posts`와 같은 것들은 클라이언트 측 설정으로, 서버에서 수신한 데이터의 표시 방식을 영향을 줍니다. 즉, 서버가 출력하는 것에 대한 추가적인 제한입니다.)
> [@hugh](#):
>
> 1. 사용자 프로필의 관리자 보기에서는 이름이 항상 표시되어야 합니다. 이는 어떤 설정과 관계없이 적용됩니다.
> 2. 이름은 사용자가 허용된 그룹에 속해 있을 때만 이메일에 표시되어야 합니다.
새로운 그룹별 설정이 사용 가능해지면 거의 모든 사람이 원할 것이므로, `enable_names`가 true인 경우 (1)은 처리된다고 생각합니다.\[2\]
(2)는 제가 발견하고 처리했다고 생각합니다 — 대부분은요.\[3\]
전체 이름이 누출되는 다른 몇 가지 사례를 기억합니다.\[4\]
어쨌든, 이번 주에 메모를 검토하고 PR을 제출하려고 하며, 그 과정에서 미해결 질문/미완성 사항을 정리하겠습니다.
* * *
1. …여러 가지 이유가 있는데, (a) 해당 설정의 실제 의도가 무엇인지 확실하지 않았기 때문(위에서 이전 게시물에 질문을 남겼습니다)이며, (b) 이를 유지하면 더 안전한 점진적 업그레이드 경로를 제공할 수 있기 때문입니다.
2. …`enable_names = false`가 "이 사이트는 어떤 방식으로든 전체 이름을 사용하지 않습니다"라는 입장을 취한다면.
3. 예: 어떤 주소로 초대 이메일이 발송될 때(사용자와 관련이 없으므로 초대 없이도 됩니다), 이메일에 초대자의 전체 이름이 포함되는지 여부?
4. 예: `oneboxer.rb`에서 로컬 사용자를 oneboxing할 때, 전체 이름이 조리된 게시물 콘텐츠에 기록되어 모든 사람에게 영원히 표시됩니다.
---
### Author:  [@hugh](https://meta.discourse.org/u/hugh)
#### Post date: [5월 28, 2025, 3:58오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/41 "2025-05-28T03:58:54Z")
정말 좋습니다! 여기에 PR 링크를 올려주시겠어요? 그러면 엔지니어에게 더 자세히 검토해 달라고 하겠습니다.
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [5월 29, 2025, 12:35오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/42 "2025-05-29T00:35:59Z")
첫 번째 PR(총 2~3개 중)이 여기에 있습니다:
>
>
> This commit is based on the premise that every serializer should have a \`scope\` …parameter which is an instance of a \`Guardian\`.
>
> In many places, serializers which construct other serializers neglect to forward their \`scope\` parameter to the sub-serializer. When one of these sub-serializers is later modified to make use of its scope in a new way or under a new circumstance, the missing scope along certain code paths can cause failures which are hard to debug. It is difficult to pin down where, within a chain of serializers, the scope has not been forwarded.
>
> This commit fixes all the current call-sites (in code with test coverage), where a serializer has neglected to forward its scope. It also introduces a mechanism to track where other classes fail to provide a scope when constructing a serializer. This mechanism will cause the codebase to evolve to a state where all serializers are reliably and predictably provided with a \`Guardian\` as their scope.
>
> Elements of this commit:
>
> 1. Modify \`ApplicationSerializer#new\` to log/raise an error if a serializer is constructed without a \`scope:\` argument. (Error is raised only in a test environment.)
>
> 2. Add a \`scope: scope\` argument to every call-site where a serializer is constructed \*by another serializer\* (forwarding sites) and the \`scope:\` argument is missing.
>
> 3. Define \`PlaceholderGuardian\`, to be used to provide a \`scope:\` argument wherever one was missing in a non-forwarding serializer construction.
>
> 4. Add a new \`scope: PlaceholderGuardian.new\` argument to every remaining (non-forwarding) call-site where a serializer is constructed without a \`scope:\` argument. (Call-sites which already have a \`scope:\` argument have been left untouched, even if it assigned the \`scope\` to \`nil\`.)
이 PR은 후속 PR의 선행 조건으로, `Guardian` 인스턴스가 실제로 한 시리얼라이저에서 다음 시리얼라이저로 전달되도록 보장합니다. 자세한 내용은 PR/커밋 메시지에 있습니다. 다음 PR을 준비하는 동안 이 PR에 대한 논의를 시작해도 좋을 것 같습니다.
> **내 미니 GitHub 계정 모험**
>
> > …글쎄요, 제가 여기서 수정 상자에 URL을 입력하기 전까지는 **있었었는데** …그리고 나서 제 계정이 갑자기 정지되었습니다. 🧐 🙀 🤬 😿 👽
> >
> > 계정 복원 요청을 접수했으며, 업데이트가 있으면 이 곳에 알리겠습니다.
>
> 13시간 후, 기본적으로 "이런 일은 가끔 발생하니 지금은 괜찮다"는 내용의 이메일을 받았습니다. 매우 카프카식이었죠. 제 계정은 사이트에서 사라졌고 — 제가 수년 전 이슈/PR에 남겼던 게시물들까지 사라져서, 누군가(저)가 그곳에 있었다는 유일한 증거로 몇 개의 유령 같은 인용 블록만 남긴 채, 기묘한 일방적인 대화들이 남게 되었습니다.
>
> 정지된 계정뿐 아니라, 프로젝트들의 역사 일부가 조용히 지워지는 점까지 고려하면, 이는 매우 무겁고 과도한 대응으로 보입니다.
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [5월 30, 2025, 8:00오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/43 "2025-05-30T20:00:57Z")
이 작업이 discourse 플러그인 저장소에서의 변경 사항 조정도 포함될 것이라는 점을 깨닫고 있습니다. 이는 테스트가 항상 통과하도록(물론 `main` 브랜치가 항상 기능적으로 유지되도록) 안쪽에서 바깥쪽으로 순서대로 진행될 PR(풀 리퀘스트) 체인을 의미합니다.
순서는 다음과 같을 것으로 예상됩니다(여기서 CORE는 `discourse/discourse` 저장소 내 PR을, PLUG는 공식 플러그인 저장소 내 PR을 의미합니다):
1. 직렬화기(serializer) 스코프 전달 강제 적용 _(기능 변경 없음 예상)_
a. CORE 직렬화기 스코프 체크 구현, 기본값은 비활성화
b. PLUG 스코프 전달 관련 수정
c. CORE 스코프 전달 관련 수정 및 스코프 체크 기본값 활성화
2. 4단계에 필요한 곳에 `Guardians`(플레이스홀더 대체)를 선제적으로 제공 _(기능 변경 없음 예상)_
- CORE 플레이스홀더 수정
- PLUG 플레이스홀더 수정
3. `enable_names`에만 의존하는 간단한 `Guardian#can_see_full_names?` 구현 _(기능 변경 없음 예상)_
- CORE `Guardian`에 메서드 추가
4. 전체 이름이 출력되는 모든 곳에서 `can_see_full_names?` 사용 (적절한 경우 `enable_names`의 단순 사용을 대체) **(기능 변경 가능성 있음)**
- CORE 새 `Guardian` 메서드 사용
- PLUG 새 `Guardian` 메서드 사용
5. `full_names_visible_to_groups` 설정 구현 **(기능 변경 있음)**
- CORE 설정에 새 항목 추가 및 `Guardian` 메서드에서 해당 설정 확인
(1)과 (2)는 Discourse 코드베이스 전반에서 `Guardians`가 더 일관되고 신뢰할 수 있도록 사용되도록 보장하는 것으로 귀결됩니다.
(3)과 (4)는 백엔드에서 전체 이름이 노출되는 시점을 제어하기 위한 더 정밀한 추상화를 도입하는 것입니다(`Guardian`이 나타내는 컨텍스트에 따라 노출 여부를 결정하는 것).
(5)는 결국 그룹 구성원 자격에 따라 전체 이름 노출을 제어하는(상대적으로 단순한) 부분입니다.
---
### Author:  [@hugh](https://meta.discourse.org/u/hugh)
#### Post date: [6월 2, 2025, 2:16오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/45 "2025-06-02T02:16:05Z")
감사합니다! 엔지니어 한 분을 이 스레드에 초대해서 확인해 보게 했습니다. 지금 진행 방향이 잘 맞는 것 같지만, 엔지니어가 더 정확한 피드백을 드릴 수 있을 거예요 🙂
---
### Author:  [@ked](https://meta.discourse.org/u/ked)
#### Post date: [6월 11, 2025, 7:47오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/48 "2025-06-11T19:47:02Z")
@hugh 이 사안을 적절한 사람들에게 전달해 주셔서 감사합니다. 우리는 이미 오래전부터 이 결과를 기다리고 있었습니다.
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [6월 13, 2025, 5:31오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/49 "2025-06-13T05:31:01Z")
> [@mdoggydog](#):
>
> 이 PR은 후속 PR(들)의 선행 조건이며, `Guardian` 인스턴스가 실제로 하나의 직렬화기(serializer)에서 다음 직렬화기로 전달되도록 보장합니다. 세부 사항은 PR/커밋 메시지에 있습니다. 다음 PR을 준비하는 동안 이 PR에 대한 논의도 시작할 수 있을 것입니다.
죄송합니다만, 이 PR은 거부해야 합니다. 해당 변경 사항은 너무 복잡하고 유지보수가 어렵습니다. 주요 이유는 다음과 같습니다:
- Scope은 항상 필요한 것이 아니며, 강제 적용해서는 안 됩니다.
- 플러그인 등 모든 곳에서 변경하고 나중에 유지보수하는 것은 막대한 작업이 될 것입니다.
- `PlaceholderGuarian`은 문제를 해결하지 않고 가짜 scope를 추가하는 것입니다(나중에 수정할 의도로).
- 대부분의 경우 직렬화는 컨트롤러에서 이루어져야 하며, scope는 자동으로 추가됩니다.
그룹에 따라 사용자 이름이나 전체 이름을 표시하는 것은 다소 까다로운 문제입니다. 이를 핵심 Discourse에 통합하려는 시도를 중단하고, 플러그인을 만들어 시작할 수는 없을까요? 커뮤니티가 작다면 다음과 같이 작동할 수 있습니다:
- `SiteSetting.enable_names`를 false로 설정하여 항상 사용자 이름을 사용하도록 합니다.
- TL3 사용자의 사용자 이름 → 전체 이름 맵을 반환하는 엔드포인트를 정의합니다.
- `formatUsername` API 호출을 사용하여 TL3 사용자의 경우 전체 이름을 추가하거나 대체합니다 - [https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse/app/lib/plugin-api.gjs#L1711](https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse/app/lib/plugin-api.gjs#L1711)
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [6월 13, 2025, 5:32오전 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/50 "2025-06-13T05:32:57Z")
원래 문제를 해결하는 PR을 방금 마무리했습니다. Admin은 항상 전체 이름을 볼 수 있고 수정할 수 있습니다. 다음 주 초에 머지할 예정입니다 🤞
>
>
> There is a bug that when \`SiteSetting.enable\_names\` is disabled, the admin can c…lick the pencil next to the user and successfully update the name. However, the change is not saved as the action is blocked by the guardian.
>
> Meta: https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [6월 13, 2025, 5:02오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/51 "2025-06-13T17:02:37Z")
> [@kris.kotlarek](#):
>
> 원래 문제를 해결하는 PR을 방금 마무리했습니다. 관리자는 항상 전체 이름을 보고 수정할 수 있습니다.
`enable_names` 설정이 실제로 무엇을 해야 하는지에 대해 여전히 근본적인 오해 또는 의견 차이가 있는 것 같습니다. 이는 다음 질문으로 귀결됩니다:
- `enable_names` 설정은 다음 중 어떤 의미를 가질 의도인가요?
1. “전체 이름을 공개적으로 표시하지 않는다.”
2. “이 사이트는 아예 전체 이름을 사용하지 않는다.”
이 주제에 대한 일부 사람들은 (1)이라고 생각하고, 다른 사람들은 (2)이라고 생각합니다. 제 인상으로는 후자, 즉 `enable_names`가 사이트가 전체 이름을 아예 사용할지 여부를 결정한다는 것입니다.
`enable_names`가 꺼져 있을 때를 생각해 보세요:
- 가입 대화상자에 전체 이름 필드가 제공되지 않습니다.
- 사용자는 자신의 계정 설정 페이지에서 전체 이름 필드를 볼 수 없으며, 어디서든 자신의 전체 이름을 볼 수 없습니다.
관리자만, 그리고 관리자만이 시스템에 전체 이름 필드가 존재한다는 사실을 아는 사이트의 사용 사례를 이해할 수 없습니다. 제 상상력이 부족해서인지, 여기에서 실제로 그런 기능을 원하는 사람이 있는지 의심스럽습니다. 만약 그런 기능을 원하시는 분이 계시다면, 제발 알려주세요!
(제 초안 PR이 무엇을 이루려는 것인지, 어떻게, 그리고 왜 그런지에 대해서도 일부 오해가 있는 것 같습니다. 하지만 먼저 "`enable_names`가 실제로 무엇을 하는가?"라는 질문에 대해 다루고 싶었습니다.)
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [6월 13, 2025, 6:06오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/52 "2025-06-13T18:06:56Z")
> [@mdoggydog](#):
>
> 관리자만, 그리고 오직 관리자만이 시스템에 이름(실명) 필드가 존재한다는 사실을 아는 사이트의 사용 사례를 이해하지 못하겠습니다. 제 상상력이 부족해서 여기에서 실제로 그것을 원하는 사람이 있는지에 대해 회의적입니다. 만약 그런 사람이 있다면, 제게 알려주십시오!
네, 수많은 예를 들 수 있습니다. 커뮤니티를 소유한 기업은 고객들의 이름을 알릴 법적 권리(및/또는 필요성)가 있는 경우가 많지만, 개인정보 보호법은 그 이름들을 제3자에게 공개하는 것을 금지합니다. 대량 이메일에서 CC를 사용하는 것이 금기인 것과 거의 같은 이유이며, BCC를 사용해야 하는 것과도 같습니다.
> [@mdoggydog](#):
>
> `enable_names` 설정이 정확히 무엇을 해야 하는지에 대해 여전히 근본적인 오해/불일치가 있다고 생각합니다
글쎄요, 이것은 단순히 동작이 이상했던 꽤 단순한 버그 보고서로 시작되었습니다. 그리고 나서 우리는 그것이 무엇을 해야 하는지에 대한 논쟁으로 빠져들었고, 그로 인해 많은 혼란과 추가적인 논의가 발생했습니다. 그것은 괜찮지만, #Contribute > Feature 주제에서 다루는 것이 더 나았을 것입니다.
> [@mdoggydog](#):
>
> `enable_names` 설정은 다음을 의미하도록 의도된 것입니까?
>
> 1. “이름(실명)을 공개적으로 표시하지 않는다.”,
> 2. “이 사이트는 이름(실명)을 전혀 사용하지 않는다.”
1번입니다. 해당 설정의 설명은 다음과 같습니다:
_사용자의 이름(실명)을 프로필, 사용자 카드 및 이메일에 표시합니다. 이름(실명)을 모든 곳에서 숨기려면 비활성화하십시오._
이름(실명)이 숨겨진다는 사실은 그것이 존재함을 의미하며, 관리자는 숨겨진 것을 볼 수 있습니다.
또한 `display_name_on_posts`, `full_name_requirement` 및 `display_name_on_email_from`도 있습니다.
2번을 원하신다면, `full_name_requirement`를 기반으로 하여 거기에 ‘Never’(절대) 옵션을 추가하는 것이 더 합리적일 것 같습니다.
(그리고 네, `enable_names`가 다른 이름으로 불려야 한다는 데 동의합니다. 하지만 설정 이름을 변경하는 일은 결코 쉽지 않습니다). 그리고 또한
> [@mdoggydog](#):
>
> `enable_names`가 꺼져 있을 때를 기억하십시오:
>
> - 가입 대화상자에 이름(실명) 필드가 제공되지 않습니다
이 부분은 이상하다고 생각합니다.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [6월 13, 2025, 7:36오후 UTC](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912/53 "2025-06-13T19:36:03Z")
> [@kris.kotlarek](#):
>
> 원래 문제를 해결하는 PR을 방금 마무리했습니다. 관리자(admin)는 항상 전체 이름을 보고 편집할 수 있습니다. 다음 주 초에 머지(merge)를 시도할 예정입니다.
이 수정으로 원래 기능이 복원될까요? 즉, 관리자와 사용자가 자신의 전체 이름을 볼 수 있게 되는 건가요? 이 변경 사항이 원래 기능에 비해 처음부터 많은 문제를 일으킨 것 같습니다. 일부 상황에서는 실명 확인이 필요하거나 바람직할 수 있으므로, 전체 권한을 가진 모더레이터(full moderator)에게도 설정을 통해 실명을 볼 수 있는 옵션이 제공되어야 합니다.
팀이 이 변경 사항을 적용한 후, 실명을 입력했던 모든 사용자의 이름이 공란으로 변했습니다.
개인적으로 이 설정은 명확한 정의가 있는 두 개의 설정으로 분리되어야 한다고 생각합니다. 이름 비활성화라는 새로운 기능은 실명을 끄는 별도의 새로운 설정이어야 합니다.
저는 작은 커뮤니티를 운영하고 있어 다행입니다. 수천 명의 회원이 있는 사이트에서 그들의 실명이 공란으로 변한다면 상상조차 하기 싫습니다.
[이전 페이지](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912.md?page=1)
[다음 페이지](https://meta.discourse.org/t/disabling-enable-names-makes-admin-act-strange/291912.md?page=3)