문제없습니다! disallowed_groups가 도움이 될 것 같아 기쁩니다. 해당 PR을 이제 병합했습니다.
disallowed_groups와 resolve_group_memberships를 사용할 수 있게 되었으므로, 이제 모든 공식 테마와 컴포넌트를 점검해야 합니다. @moin 님도 시간이 나시면 본인의 테마와 컴포넌트에 대해 동일한 작업을 해주시면 좋겠습니다. 공식 저장소에 변경 사항을 적용한 후, OP의 stable 버전으로의 전환을 본격적으로 진행하기를 정말 원하기 때문입니다.
현재 anonymous_users와 logged_in_users에 의존하거나 이를 사용하는 핵심 작업이 많으며, everyone 그룹을 삭제하기를 정말 원합니다.
martin님, 질문 하나 있습니다:
방금 인스턴스를 전체 업데이트했고, 이제 everyone과 anonymous_users에 대해 이 자동 그룹 ID를 기반으로 컴포넌트에 disallowed_groups 객체 설정을 추가하고 있습니다:
아래와 같이 설정했습니다:
groups:
type: groups
disallowed_groups: "0|4"
required: true
resolve_group_membership: true
validations:
max: 20
하지만 여전히 컴포넌트 그룹 드롭다운 설정에 everyone이 표시됩니다:
객체 설정에서 제가 무엇을 잘못하고 있나요? disallowed_groups를 객체에 설정하지 않아도 anonymous_users 그룹이 표시되지 않는다는 것을 알아차렸습니다(즉, 현재는 disallowed_groups를 설정하든 아니든 제 컴포넌트의 목록에 차이가 없습니다). 다른 그룹 ID로 테스트해 봤는데, disallowed_groups를 사용하는 방법(또는 구문)에 뭔가 잘못되고 있는 것 같습니다. 어떤 것을 사용하든 효과가 없는 것 같으니까요.
오늘早些에 GitHub에서 문제가 발생해서, disallowed_groups 변경 사항이 이제야 최신 Commits · discourse/discourse · GitHub 버전으로 반영되었습니다.
정확한 원인이 될지는 확실하지 않지만, 다시 업데이트를 시도해 보시고 문제가 계속되는지 확인해 주시겠어요? 아니라면 알려주시고, 테마 컴포넌트(그룹 사이드바 하나만 해당되나요?)를 알려주시면 디버깅을 도와드리겠습니다 
테스트에 사용하신 포럼에서 예정된 변경 사항이 비활성화되어 있었기 때문인 것 같습니다. 활성화했더니 이제 보입니다.
everyone과 anonymous_users가 예상대로 숨겨진 상태입니다.
정리하자면: 이 변경 사항을 약 2주 전에 비활성화한 사람은 저입니다 
하하 
모인, 고마워! 사실 새 그라뉘러 그룹 설정이 예정된 변경 사항에 이미 포함되어 있다는 걸 잊고 있었어.
마틴, disallowed_groups 객체 설정이 완벽하게 작동해. 이 변경 사항을 정말 좋아해. 팀에게 다시 한번 감사해 - 정말 멋진 개선이야. 
익명 사용자와 등록 사용자의 CSS 클래스를 알려 주실 수 있을까요? 순수 CSS를 사용 중이라 내부 ID는 사용하지 않고 있습니다.
기본적으로 body에 이러한 CSS 클래스를 추가하지 않습니다. CSS Classes for Current User's Groups 을 말씀하시는 건가요?
해당 컴포넌트를 업데이트하여 현재 사용자가 있는지 여부에 따라 group-anonymous 또는 group-logged-in-users를 추가하도록 수정해야 합니다.
Martin, 안녕 
테마 컴포넌트에 두 클래스(anonymous_users와 logged_in_users)를 추가하기 위해 간단한 PR을 열었습니다. 하지만 정말로 필요한지는 아닌 것 같습니다(아래 메모 참고).
아직 제대로 테스트해 보지는 못했습니다(ㅋㅋ)만, 꽤 직관적인 것 같습니다. 코드는 현재 사용자가 존재하는지 확인하고, 존재하면 logged_in_users 멤버가 되고, 그렇지 않으면 anonymous_users가 됩니다. 
메모: 해당 컴포넌트 없이도 이러한 익명/로그인 상태 CSS를 사용할 수 있습니다. Discourse가 기본적으로 .anon을 자동으로 추가하므로, 컴포넌트를 설치하지 않고도 익명 사용자와 로그인 사용자를 위한 CSS를 구현할 수 있습니다. 다만 이 PR은 단순히 새로운 그룹 규칙을 사용하기 위한 코드를 추가하는 것입니다.
예를 들어, 다음과 같은 코드가 있습니다:
// 익명 사용자의 경우
@if $hide_this_from_anon {
html.anon {
.something {
display: none;
}
}
}
// 로그인 사용자의 경우
@if $hide_this_from_logged_in_users {
html:not(.anon) {
.something {
display: none;
}
}
}
아, 맞아요. 전에 그걸 알아채지 못했네요. <body>만 보고 있었거든요 :
그래도 컴포넌트 PR은 승인해 드릴게요. 괜찮다고 생각합니다
참고로, 아직 여기에 게시글을 올리지 않았지만, 공식 컴포넌트에서 resolve_group_membership와 disallowed_groups를 사용하도록 다음과 같은 PR들을 병합했습니다:
현재 이 다가오는 변경 사항의 다음 단계에 대한 계획을 세우고 있습니다. 코어/플러그인 코드베이스에는 여전히 everyone을 직접 참조하거나 서버 측에서 user.in_any_groups?를 사용하지 않는 부분이 남아 있는 것 같습니다.
아직 병합되지 않은 이유가 있을까요?
이 주제를 만든 이유는 마침 내 컴포넌트를 업데이트했기 때문입니다.
그렇게 했습니다. 하지만 여전히 이 변경이 제가 이 값을 수정한 후에야 해당 컴포넌트를 추가하는 포럼에만 도움이 되는 것 같습니다. 이미 컴포넌트를 사용 중인 포럼에는 새로운 기본값이 적용되지 않습니다(이것은 보통 좋은 일입니다!). 따라서 여전히 컴포넌트를 이미 사용 중인 사용자에게 예상치 못한 동작 변경이 발생하는 문제를 보고 있습니다.
또한, 관리자가 제가 업데이트에서 허용되지 않는 그룹(disallowed group)으로 추가하는 그룹으로 설정을 구성한 경우 어떤 일이 발생하는지 아시나요?
이 컴포넌트가 많은 포럼에서 사용되지 않는다고 생각해서 크게 걱정하지 않고 병합했지만, 마이그레이션과 허용되지 않는 그룹 설정은 다른 테마 개발자들도 관련이 있을 수 있습니다.
아니요, 어쩐 일인지 제 뇌가 이것이 discourse 조직의 PR이 아닌 것으로 생각했던 것 같습니다 
CI 체크가 실행된 후 곧 병합하겠습니다.
이러한 경우와 미래의 다른 경우들을 위해, 테마/컴포넌트별로 마이그레이션을 작성하는 것이 최선의 방법일 것 같습니다 Migrate Discourse theme settings
위에서 작성한 게시글에서 이 작업이 언제 이루어져야 하는지 질문했습니다. 새 그룹이 모든 포럼에서 정상적으로 작동하는지 확신하지 못한 채 마이그레이션을 진행하면 다른 문제도 발생할 수 있고, 관리자는 해당 변경 사항을 켜고 끌 수 있습니다. 그래서 적절한 시기에 마이그레이션을 진행하는 것이 불가능해 보입니다.
이미 언급된 내용이었다면 죄송합니다. 놓쳤다면…
resolve_group_membership가 설정에 포함된 경우, user_in_ 접두어를 통해서만 boolean 값을 접근할 수 있고, 설정 필드의 원시 값(raw value)에는 더 이상 접근할 수 없다는 사실을 깨달았습니다.
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // undefined
console.log(settings.user_in_aabbccdd_allowed_groups); // true 또는 false
이것이 의도된 동작인가요?
그렇다고 생각합니다. 그렇지 않았다면 이 버그에 대한 해결책이 달랐을 수도 있었을 테니까요.
저도 그렇게 생각합니다. user_in_x는 프론트엔드가 인식하지 못하는 그룹도 검사합니다. 이는 해당 그룹이 관리자만 볼 수 있거나, everyone과 같이 기본적으로 가시성이 제한되어 있기 때문입니다. 따라서 어떤 것을 사용하느냐에 따라 결과가 달라질 수 있으므로, 두 가지를 조합하면 의도하지 않은 결과가 발생할 수 있습니다.
Moin, 감사합니다. 정확히 말씀하신 대로입니다. @gormus, 실제 그룹 ID가 여전히 표시되는 유일한 곳은 테마 설정의 관리자 UI입니다.
이전에 제가 올린 내용만으로 명확하지는 않을 수 있지만, anonymous_users와 logged_in_users는 다가오는 변경 사항이 활성화되지 않아도 언제든지 사용할 수 있습니다. 이 두 항목은 몇 달 전에 독립적으로 추가했기 때문입니다. 다가오는 변경 사항의 주요 기능은 다음과 같습니다:
따라서 어떤 경우든, everyone이 사용되는 모든 곳에서 이를 제거하고从现在부터 anonymous_users와 logged_in_users만 사용한다면 안전합니다.
오늘은 사이트 설정에서 everyone을 완전히 제거하기 위해(현재는 카테고리 설정은 그대로 두고) 제가 수행해야 할 나머지 작업에 대한 계획을 세우고, 그 내용을 여기에 게시할 예정입니다. 이렇게 하면 앞으로 동일한 이해를 바탕으로 진행할 수 있을 것이고, 작업을 진행하면서 이 계획을 계속 업데이트해 나가겠습니다.
하지만 변경 사항이 비활성화되어 있으면 인터페이스에서 그룹이 표시되지 않습니다. 관리자는 해당 그룹에 대한 설정을 변경할 수 없습니다. 따라서 "everyone"을 disallowed_group으로 추가하면 방문자에게 표시되도록 구성할 수 있는 그룹이 더 이상 표시되지 않습니다. 저에게 "사용 가능(usable)"이란 단순히 작동하는 것뿐만 아니라 표시되는 것을 의미합니다. 여전히 변경 사항을 비활성화할 수 있으므로, 새로운 그룹에만 의존하는 것을 "안전한(safe)"이라고 부르지는 않겠습니다.
음, 맞아요. 이 disallowed_group 문제가 사라지려면 다가오는 변경 사항이 비활성화된 상태에서 추가로 수정해야 할 부분이 몇 가지 있습니다:
anonymous_users와 logged_in_users가 그룹 선택기에 아예 포함되어 있지 않습니다. 이제 여기에서 이들을 허용하는 것이 안전할 것 같으며, 그렇게 하면 다가오는 변경 사항이 꺼져 있어도 everyone을 disallowed_groups에 추가했는지 여부가 중요하지 않게 됩니다.anonymous_users를 존중하도록 Guardian::AnonymousUser#in_any_groups?를 수정해야 합니다.0 (everyone) → 5 (logged_in_users) 읽기 시간 별칭을 추가해야 합니다.다가오는 변경 사항이 아직 선택 사항이고 비활성화된 동안, 그룹 선택기에서 everyone에 (legacy) 표시를 추가하는 것도 고려해 볼 수 있습니다.
이 항목들을 우선 처리하고, 현재 작성 중인 전체 계획에 포함시킬 예정입니다.
여기에서 @moin 님을 위해 전용 주제를 만들었습니다: The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . 원본 글은 아직 완성되지 않았으며, 저는 로컬에서 모든 케이스를 검토하고 있고 계속 업데이트해 나갈 것입니다. 이 주제에 계속 게시해도 괜찮지만, 원본 글의 일부를 인용하거나 적절히 추가할 수 있도록 새로운 주제에서 추가 논의를 진행해 주셨으면 합니다.