管理者のノイズを無視！

[Lilly (Lillian)]

	概要	管理者向けのユーザーメニュー内の各種通知を自動的に非表示にします
	リポジトリ	https://github.com/Lillinator/dismiss-admin-noise
	インストールガイド	テーマまたはテーマコンポーネントのインストール方法

このテーマコンポーネントをインストール

概要

管理者のユーザーメニュー内にある特定のシステム通知を自動的に非表示（dismiss）にする、軽量な Discourse テーマコンポーネントです。

このコンポーネントは、UI のノイズと認知負荷を軽減することを目的としています。特に、神経多様性のある管理者（私のような）や、インスタンスの更新を頻繁に行い Meta で変更を追跡している人（私のような）、あるいは開発フォーラムで常に最前線に立つ YOLO 系の管理者（これも私）に役立ちます！

設定

以下の通知は、コンポーネントの管理者設定で自動的に非表示にすることができます。

設定	説明
No new features notifications	新機能に関する通知を非表示
No invitee accepted notifications	招待承諾に関する通知を非表示
No membership accepted notifications	グループへの参加承諾に関する通知を非表示（注：参加通知の統合には影響しません）
No granted badge notifications	付与されたバッジに関する通知を非表示
No upcoming change promoted notifications	自動的に公開された今後の変更に関する通知を非表示
No review queue badges	管理者がモデレーターグループのメンバーではない場合、レビュー可能なフラグに関する通知を非表示

設定のスクリーンショット

重要な注意点

• 影響を受けるのは管理者ユーザーのみです。例えば、このコンポーネントで設定が有効化されていても、非管理者は付与されたバッジや承諾された招待の通知を受け取り続けます。

• No review queue badges 設定は、管理者がモデレーターグループのメンバーではない場合にのみ、フラグ通知に影響します。ただし、フラグの数はレビューキューのサイドバーに表示され続けるため、管理者は依然として追跡できます。

• 設定はすべての管理者ユーザーに影響します。管理者グループ内の特定の管理者のみを対象とするような細かな設定はできません。これは、preferences/notification タブに設定を追加するプラグインとして開発する必要がありますが、現時点では作る気力がありません。もちろん、予算があり開発を依頼してくださる場合は別ですが。

• コンポーネントのすべての設定が有効になっている場合、フォーラムの通知の繁忙度によっては、その他の通知 タブや すべての通知 タブが空になる可能性があります。

• 今後の変更 に関する管理者通知は、ユーザー設定 -> 通知 の設定で自動的に非表示にすることができます。

• このコンポーネントのせいで重要な通知を見落としたとしても、私は責任を負いません！

---

他の Discourse 関連作品をチェック

[haydenjames]

@Lilly

神経多様性の管理者（私のように）

もしかしてこれが原因かもしれませんね（笑）。私はADHDと診断されています。数分前にスクリーンショットを撮っておけばよかったと後悔していますが、目覚めたら約30件の招待が承認されていて、通知ボックスには最後の15件しか表示されていませんでした（招待がドロップダウンのすべての枠を埋めてしまうため、/u/hydn/notifications にアクセスして確認したくありません）。少なくとも、それを管理する組み込みの方法がないのは、少し不快感を覚えることです。

ありがとう！

[Lilly (Lillian)]

ちなみに、これらの通知をトリガーする実際のアクションを実行せずにコンポーネントの設定をテストしたい場合（SSH アクセス権がある場合）、Rails コンソールで以下のコマンドを使用して、それぞれのイベント通知をトリガーできます（コンポーネントの設定に適用されるトリガーを使用してください）：

cd /var/discourse
.launcher enter app
rails c

# ユーザー変数を見つけ、設定する
u = User.find_by_username("YOUR ADMIN USERNAME")

# トリガー：新機能
Notification.create!(
  user: u,
  notification_type: Notification.types[:new_features],
  read: false,
  data: {}.to_json
)

# トリガー：招待者の承認
Notification.create!(
  user: u,
  notification_type: Notification.types[:invitee_accepted],
  read: false,
  data: { display_username: "awesome_new_user" }.to_json
)

# トリガー：グループメンバーシップの承認
Notification.create!(
  user: u,
  notification_type: Notification.types[:membership_request_accepted],
  read: false,
  data: { group_name: "Trust_Level_4" }.to_json
)

# トリガー：バッジの付与
Notification.create!(
  user: u,
  notification_type: Notification.types[:granted_badge],
  read: false,
  data: { badge_name: "Great Topic", badge_id: 10 }.to_json
)

# トリガー：予定変更の自動昇格
Notification.create!(
  user: u,
  notification_type: Notification.types[:upcoming_change_automatically_promoted],
  read: false,
  data: { 
    upcoming_change_humanized_name: "Experimental CSS",
    upcoming_change_name: "experimental_css"
  }.to_json
)

# ブロードキャスト（別のウィンドウまたはタブでブラウザを確認してください！Enter キーを押したときに通知が表示されます）
u.publish_notifications_state

最も効果的なテスト方法は、テスト対象のコンポーネントで設定を無効にし、関連する Rails トリガーコマンドを実行して通知ポップアップが表示されることを確認し、その後設定を有効にしてハードリフレッシュを行うことで通知が消えることを確認することです。

[asa]

ありがとうございます。今日どうしてもそれを探していました。毎日それについての通知が届くので、ほぼ狂ってしまいました！lol

[mcwumbly (Dave McClure)]

管理者（およびユーザー）が、どの通知を受け取るか、受け取らないかをより細かく制御できる仕組みがあれば良いと思います。

その間、必要としている人々のために、このような動作する例が公開されているのは素晴らしいことです。

[Lilly (Lillian)]

大量通知（多数のバッジが同時に通知される場合など）に対する改善を行いました。また、管理者がモデレーターグループのメンバーでない場合、レビューキューから保留中のフラグ通知を自動的に消去する新しい設定を追加しました。サイドバーのレビューキューセクションにはフラグの数が引き続き表示されるため、管理者はユーザーメニューで通知が煩雑にならずに追跡を続けることができます。