아니요, 그렇지 않았습니다. 내부와 외부에서, 그리고 코드베이스 전체에서 이 문제가 반복적으로 제기되어 왔습니다.
카테고리 부분은 아직 다루지 않았으며, 여기서는 아무것도 변경되지 않았습니다.
더 나은 표현 방법이 없었기 때문에 사람들이 '모든 로그인한 사용자’를 의미할 때 TL0을 압도적으로 많이 사용했습니다. logged_in_users 그룹은 적어도 그것이 무엇을 포함하는지 완전히 명확하며, 여전히 TL0/TL1 등을 사용하는 것을 막는 것은 전혀 없습니다. 제거되는 그룹은 everyone 하나뿐입니다.
네, 맞습니다. 저는 모든 것을 "변화를 위한 변화"로만 하고 있습니다 
잠시 말투를 돌아봐 주세요. 우리는 여기서 이유 없이 전혀 불필요한 일을 하는 습관이 없습니다. 이 작업은 몇 달 동안 진행되어 왔으며 방향이 바뀌는 것은 아닙니다.
음, 제가 이 변경 사항을 오해하고 있는 건가요?
제안 내용이 다음과 같은 자동 그룹을 도입하는 것이라면:
그건 괜찮아 보이고, 이름만 봐도 용도가 명확합니다.
(사실 꽤 마음에 듭니다! )
하지만 제안 내용이 결국 다음을 제거하는 것이라면:
그건 제게는 이해가 가지 않습니다. everyone은 접근 권한의 임계값을 나타내는 자동 그룹들의 일부이기 때문입니다. 그 그룹에는 다음도 포함됩니다:
등등.
이들은 모두 everyone을 포함하여 접근 권한의 임계값을 나타냅니다.
everyone 그룹은 즉 "trust_level_none"입니다.
이는 공개 접근(public access)을 간결하게 표현하는 방법입니다.
현재로서는 카테고리 권한에서 이를 제거할 의도가 없다는 점은 이해합니다() 하지만 개인적으로는 이 자동 그룹을 유지하겠다는 확약이 있었으면 합니다. 적어도 제게는 이게 훨씬 합리적이기 때문입니다.
그렇다면 왜 이 자동 신뢰 수준(trust level) 그룹처럼 다른 곳에서도 사용할 수 있게 하지 않을까요?
그렇지 않으면 "공개 접근"을 표현해야 하는 모든 곳에서 두 개의 그룹을 추가해야 하는데, 이는 불필요한 복잡성으로 보입니다?
"everyone"을 “가려내기(mask out)” 위한 로직을 추가하는 데 왜 애를 쓸까요?
혹시 더 나은 이름이 있다면 "everyone"이라는 이름을 재고하되, 그 의미와 기능, 그리고 플랫폼 전반에서의 가용성은 유지하는 것이 또 다른 대안이 될 수 있습니다. 그러면 모든 사람(숨)이 만족할까요?
여기서 구분할 점은 '공개 액세스’를 선택할 수 있는 편리한 방법을 유지하는 것과 기존 everyone 그룹을 유지하는 것 사이입니다. 공개 액세스를 원할 때마다 두 개의 그룹을 매번 선택해야 하는 것은 더 번거롭다는 데 동의하며, 이는 UI를 통해 개선할 수 있습니다.
예를 들어, 그룹 선택기에 ‘공개’ 단축키를 추가하여 anonymous_users와 logged_in_users를 한 번의 작업으로 모두 선택하도록 할 수 있습니다. 그러면 두 그룹이 모두 선택된 상태로 표시되며, 원하면 어느 하나를 제거할 수 있습니다. 이렇게 하면 여러분이 설명한 편의성을 제공하면서도 하위 권한은 명시적으로 유지할 수 있습니다. 이 단축키는 두 그룹이 모두 허용되는 곳에서만 제공될 것입니다.
기존 everyone 그룹을 유지하는 문제는 그것이 일관되게 '공개 액세스’를 의미하지 않았다는 것입니다. 카테고리 가시성의 경우 그러하지만, 대부분의 그룹 기반 사이트 설정에서는 사실상 '로그인된 모든 사용자’를 의미해 왔습니다. 또한 위의 논의에서 보았듯이 테마와 플러그인도 이를 다르게 해석하고 있습니다.
따라서 이전에는 존재하지 않았던 액세스 권한을 부여할 위험이 있으므로, 모든 곳에서 익명 사용자를 포함한다고 선언하면서 그대로 유지할 수 없습니다. 기존 동작을 유지하면 일관성 부족이 남게 되며, 이름을 변경하는 것만으로는 이를 해결할 수 없습니다.
일관되게 정의된 범용 그룹을 만드는 것은 가능하지만, 현재 진행 중인 마이그레이션 및 감사 작업이 여전히 필요합니다. 또한 익명 액세스가 지원되지 않는 곳에서는 이를 허용하지 않도록 해야 하며, 그렇지 않으면 해당 위치에서 다시 'everyone’이 '로그인된 사용자만’을 의미하게 됩니다. 이전에는 everyone이 허용되던 설정들에 anonymous_users를 disallowed_groups 값으로 추가해야 했던 경우가 매우 많습니다. 예를 들어:
저는 관리자 및 개발자를 위해 모든 곳에서 일관성을 확보하기 위해, 내부적으로는 두 개의 명시적인 그룹을 사용하면서 UI에서 그 편의성을 제공하는 방식을 선호합니다.