Discourse 사이트의 관리자(admin)이면서 동시에 모더레이터가 아닌 경우가 가능합니다. 관리자는 모더레이션과 무관한 이유로 사이트에 매우 활발하게 참여할 수 있습니다. 이 경우 플래그에 대한 알림을 원하지 않을 수 있습니다.
제안하는 방법은 사용자가 알림을 받는지가 사이트 설정에 의해 결정되도록 하는 것입니다. 예를 들어 flag_notifications_allowed_group 설정을 사용할 수 있습니다.
현재 동작을 유지하기 위해, 기본적으로 이 설정에는 관리자와 모더레이터가 포함됩니다. 하지만 관리자가 가입할 수 있는 그룹 중 알림을 받고 플래그 처리를 돕고 싶은 그룹으로 설정을 구성할 수 있습니다.
5개의 좋아요
gormus
(Osman Görmüş)
7월 3, 2026, 9:05오전
3
이 기능 요청 정말 좋아요. +1
관리자로서, 검토 대기열이나 모더레이션 관련 알림이나 참여를 전혀 하지 않는 것을 정말 원합니다.
현재 다른 유형의 알림은 모두 해제할 수 있지만, 플래그가 지정된 콘텐츠 알림만은 해제할 수 없습니다.
4개의 좋아요
Lilly
(Lillian )
7월 8, 2026, 4:02오전
4
5개의 좋아요
mcwumbly
(Dave McClure)
7월 9, 2026, 1:29오전
5
많은 사람들이 이를 좋아할 수 있다는 점을 이해합니다.
이를 해결하는 몇 가지 가능한 방법이 있습니다:
a) 첫 번째 게시물에서 제안된 대로 _groups 설정을 추가
b) 하드코딩된 그룹을 단순히 @moderators에게만 알림을 보내도록 변경하고, 알림을 받고 싶은 관리자는 스스로 모더레이터 역할도 맡도록 함
c) 개인별 알림 설정을 추가하여, 각 사용자가 이 특정 알림을 받을지 말지를 직접 제어할 수 있도록 함 (@Lilly의 테마 컴포넌트와 유사한 방식)
이 경우 (b)나 (c) 쪽이 더 적절하다고 생각합니다.
@awesomerobot 여기서는 어떤 설계가 가장 합리적이라고 생각하시나요?
2개의 좋아요
Lilly
(Lillian )
7월 9, 2026, 2:07오전
6
참고로, 비개발자로서의 제 의견은 (b)입니다.
a)는 크게 의미가 없습니다. 왜냐하면 우리는 관리자(admins)와 모더레이터(moderators)라는 두 그룹만 다루고 있고, 그중 하나인 모더레이터는 항상 플래그 알림을 받아야 하므로:
b)가 훨씬 더 간단하며, 개별 관리자는 모더레이터 그룹에 자신을 추가할지 말지 선택할 수 있습니다.
c)는 사용자가 관리자인지 확인하고 설정을 해당 사용자의 환경설정/알림 탭에 추가하기 위해 코어 코드에서 더 많은 작업이 필요하지만, 결국 (b)와 동일한 결과를 낳습니다. (솔직히 이걸 어떻게 해야 하는지 작동하는 아이디어가 있고, 이미 플러그인으로 구현해 봤습니다.)
3개의 좋아요
Lilly
(Lillian )
7월 9, 2026, 5:27오전
7
자, 그냥 장난으로 - 위에서 언급한 옵션 B에 따라 모든 플래그 알림을 Moderators 그룹의 멤버에게만 보내도록 하는 PR을 여기에 열었습니다. 따라서 Moderators 그룹의 멤버가 아닌 Admins는 플래그에 대한 어떤 알림이나 표시도 받지 않게 됩니다. 물론 원할 때마다 사이드바를 통해 검토 대기열에 들어갈 수는 있습니다.
예상대로 일부 PR 테스트가 실패할 것 같고, 아마도 린팅 문제일 겁니다. ㅋㅋ
내 오래된 친구 triage-bot이 아마도 고쳐줄 거예요
main ← Lillinator:flags-notify-mods
closed 05:14PM - 09 Jul 26 UTC
## What is the purpose of this Pull Request?
Currently, Discourse broadcasts re… view queue notifications (flags, queued posts) to the entire `staff` group. This results in significant notification noise for "pure Admins" who are not members of the Moderator group, and thus, not involved in the day-to-day moderation of the community.
Following the discussion on Meta here: https://meta.discourse.org/t/add-setting-to-not-show-flag-notification-to-admins-who-are-not-moderators/383964/5
This PR makes flags only notify the Moderators group instead of staff; thus, Admins not in the moderators group are not notified of flags nor see a review queue count indicator in sidebar (they can still go to the review queue manually as usual). That is, it mutes the active UI elements for pure Admins while preserving their underlying permission to access and action the review queue if they choose to.
### Technical Implementation:
This PR intercepts the reviewable counts at the Model and Serializer layers to securely silence the frontend without modifying underlying database permissions or the core `/review` route.
1. **Websockets & Live Updates:**
* Scoped `notify_users` to `moderators` instead of `staff` to prevent live browser "pops" for admins.
* Updated `publish_reviewable_counts` to push `0` counts to pure admins.
2. **UI Badges & Preloaders:**
* Overrode `unseen_reviewable_count` and `reviewable_count` in `CurrentUserSerializer` to clear the red avatar flag, the blue menu badge, and the sidebar count for pure admins.
* Intercepted `Reviewable.user_menu_list_for` to return an empty array for non-moderators, effectively silencing the `<meta>` tag preloader and the user menu dropdown API.
3. **Tests:** Updated `refresh_users_reviewable_counts_spec` to expect `0` for admin payloads. *(Note: CI is running, will update any other strictly `staff`-scoped spec expectations as needed!)*
### Testing Performed:
Manually verified on a live development install with three distinct user roles:
- [x] **Pure Admin (Admin = true, Moderator = false):** Receives 0 websocket pops, no red avatar badge, no blue menu badge, and an empty menu dropdown. Can still successfully manually navigate to `/review` and action pending flags.
- [x] **Pure Moderator (Admin = false, Moderator = true):** Behavior remains exactly as it was. Fully receives websockets, badges, and dropdown items.
- [x] **Hybrid Staff (Admin = true, Moderator = true):** Behavior remains exactly as it was (receives all notifications).
- [ ] **Category Moderators:** not tested yet.
### Files Touched:
* app/models/reviewable.rb
* app/models/user.rb
* app/serializers/current_user_serializer.rb
* app/controllers/reviewables_controller.rb
* spec/jobs/refresh_users_reviewable_counts_spec.rb
* spec/requests/reviewables_controller_spec.rb
수정: 죄송합니다 @Moin , 카테고리 모더레이터는 신경 쓰지 않습니다
(이 PR이 어딘가에서 카테고리 모더레이터 알림을 깨뜨렸을 가능성이 있지만, 그건 또 다른 이야기입니다…)
4개의 좋아요
Moin
7월 9, 2026, 5:29오전
8
mcwumbly:
첫 번째 게시물에서 제안한 대로 _groups 설정을 추가
새로운 그룹을 카테고리 모더레이터로 만든 사람이 해당 그룹을 설정에 추가하는 것을 잊어버리면, 카테고리 모더레이터가 통지를 받지 못하는 상황이 쉽게 발생할 수 있습니다.
@moderators에게만 통지를 보내면 카테고리 모더레이터가 해당 카테고리의 플래그에 대해 통지를 받지 못하게 됩니다. 기본 그룹에 의존하는 대신, 플래그를 처리할 수 있는 모든 모더레이터에게 통지를 보내야 한다고 생각합니다.
3개의 좋아요
gormus
(Osman Görmüş)
7월 9, 2026, 8:12오전
9
mcwumbly:
b) 하드코딩된 그룹을 @moderators로만 알림을 보내도록 변경하고, 원하는 관리자는 moderator 역할도 함께 맡도록 하는 것입니다.
궁금한 점이 있어서 질문드립니다. 해당 옵션들 중 특히 b) 옵션이 카테고리 moderator들에게 어떻게 적용될까요?
(죄송합니다. 현재 다른 업무가 많아 카테고리 moderator들에게 어떻게 작동하는지 아직 테스트해볼 기회가 없었습니다.)
2개의 좋아요
mcwumbly
(Dave McClure)
7월 9, 2026, 10:12오전
10
아, 좋은 지적입니다.
옵션 (b)를 설명하는 더 나은 방식이네요. _정신_적으로는 제가 의도했던 바로 그 뜻입니다.
이 접근 방식이 가장 좋다고 생각합니다(명시적인 추가 설정이 필요 없으므로).
2개의 좋아요
관리자 제외를 통한 플래그 알림을 기본적으로 비활성화하는 것에 대해 약간 회의적입니다. 단, 관리자를 기본적으로 모더레이터로 설정하는 경우를 제외하구요. 그 경우 흐름은 "이 알림을 원하지 않으면 스스로 그룹에서 나간다"가 되어, 알림을 받으려면 스스로 그룹에 추가해야 한다는 사실을 알아야 하는 것보다 더 자연스러워집니다.
사이트 호스팅 경험을 통해, 모더레이터가 0명인 사이트가 드물지 않다는 것을 알고 있습니다. 또한, 알림을 수신하더라도 관리자가 플래그를 매우 오랫동안 방치하는 경우가 있습니다. 이러한 상황에서 관리자의 알림을 기본적으로 제거하면 상황이 더 악화되거나, 심지어 우발적으로 발생할 수 있습니다.
mcwumbly:
개인 알림 설정을 추가하여, 개인이 이 특정 알림을 받을지 여부를 제어할 수 있도록 합니다.
이전에 특정 알림 유형을 제어할 수 있는 설정이 요청된 바 있습니다. 이는 더 큰 프로젝트이지만, 가장 합리적인 접근이라고 생각합니다.
이것은 단순한 스케치일 뿐이지만, 아이디어는 다음과 같은 형태가 될 것입니다:
4개의 좋아요
Moin
7월 9, 2026, 3:30오후
12
음. 관리자(모더레이터)에게만 전송되는 알림이 있습니다(사용자가 자동으로 차단되었거나 승인 대기 상태인 사용자와 관련된 알림이라고 생각합니다). 따라서 관리자가 없는 포럼은 이미 해당 알림을 받지 못하고 있습니다.
FEATURE: add bootstrap first admin job - Pull Request #39851%EC%97%90%EC%84%9C - discourse/discourse - GitHub 첫 번째 관리자를 동시에 관리자로 설정하는 기능을 다시 추가했다는 것을 알고 있습니다. 부트스트랩 모드가 제거되기 전에도 이 기능이 존재해 왔습니다. 따라서 현재 #uncategorized가 제거되는 방식과 유사하게, 기존 포럼에는 최소 한 명의 관리자가 있어야 한다는 것을 강제할 수 있을 것입니다.
그리고는 관리자를 위한 모더레이션 관련 알림의 기본 설정을 제공할 수 있으며, 이들은 더 복잡한 커스텀 알림 관리 변경을 통해 여전히 이를 맞춤 설정할 수 있습니다.
2개의 좋아요
mcwumbly
(Dave McClure)
7월 9, 2026, 4:33오후
13
당연한 의견입니다. 여러 다른 이유를 들어 관리자를 기본적으로 모더레이터로 지정하는 것이 적절하다고 생각합니다. 따라서 그렇지 않으면 “단순한” 이 변경 사항을 위해 여기에서 해당 필수 범위를 고려하는 데 동의합니다.
awesomerobot:
mcwumbly:
개인 알림 설정을 추가하여 개인이 이 특정 알림을 받을지 여부를 제어할 수 있도록 합니다
이전에도 특정 알림 유형을 제어할 수 있는 설정이 요청된 바 있으며, 이는 더 큰 프로젝트이지만 가장 합리적인 접근 방식이라고 생각합니다.
이것은 단순한 스케치일 뿐이지만, 아이디어는 다음과 같습니다:
이것은 관리자뿐만 아니라 모든 사용자를 위한 알림 전체의 더 일반적인 장기적 방향성으로 좋아합니다.
이것은 @Lilly가 탐색하고 있는 내용과도 일치한다고 생각합니다.
4개의 좋아요
Lilly
(Lillian )
7월 9, 2026, 5:12오후
14
개인적으로 이것은 기능상의 문제가 아니라 교육/문서화 문제라고 생각합니다.
어쨌든, 팀이 이 방향으로 진행하기를 원하지 않는 것 같으므로 제 PR을 닫았습니다.
3개의 좋아요