2017 年初頭の 以前の議論 から、バッジは制限されたグループでは機能しないことは理解しています。
この制限を回避する方法がないか検討しています。少し背景を説明します。
当グループの 99.9% は「メンバー」ロールを持つ人のみアクセス可能です。公開討論やヘルプ・サポートのために誰でも参加できるグループもいくつかあります。有料メンバーシップグループとして、これらのプライベートグループ内での活動を表彰できれば素晴らしいと思います。当グループの投稿数は 130 万件以上あり、その大部分がこれらのグループ内でのものです。
この問題を解決するための回避策や設定はありますでしょうか？
その理由は、投稿を参照するバッジがすべて badge_posts テーブルに対してクエリを実行するためです。このテーブルには、すべてのユーザーがアクセス可能なカテゴリに属する投稿のみが含まれています。
確かに、それが問題になることは理解できます。考えられる回避策として、当サイトのバッジクエリを badge_posts テーブルの代わりに posts テーブルを使用するように書き換える方法があります。これにより、保護されたカテゴリへのアクセス権を持たないユーザーが、バッジに関連する投稿を表示しようとした際に問題が発生する可能性がありますが、当サイトでは多くのユーザーには影響しないようです。他にも対応方法があるかもしれません。
正直なところ、私たちの目的にとっては、それは完全に許容できると思います。
これは簡単なことでしょうか？それとも長期的には問題になるでしょうか。
サイト内のバッジクエリを badge_posts テーブルの代わりに posts テーブルを使用するように変更するのは、比較的簡単です。ただし、この問題に対する適切な修正には、より大規模な変更が必要になるかもしれません。例えば、スタッフカテゴリの投稿や、トピックのタイトルが漏洩する懸念がある他のカテゴリの投稿に対してバッジが付与されないようにする必要があります。
類似の設定を持つサイト向けに、プラグインを通じて新しい Postgres ビューを追加できないか考えています。そのビューを badge_posts ビューの代わりにバッジクエリで使用できるかもしれません。
なるほど、この理論は気に入りました。
もしそのルートが選択肢として可能なら、そのビューにはすべての公開グループの投稿を含めることはできるでしょうか。現在あるものに加え、特定のグループ（私たちの場合は「メンバー」）に可視化されたグループも含めて。
それこそがメンバーシップグループにとって究極の解決策になるでしょう！
Discourse のエンジニアがそのようなアプローチについてどう考えているか、あるいは他の提案があるか見てみましょう。この問題は以前も報告されたことがあります。この問題に対する一般的な解決策を策定するのは良いことですが、多くのサイトに適用できる良い解決策は、私が提案しているものよりも複雑になる可能性があります。
ビューの入れ替えは好みではありません。
@mitchelsellers への私の提案は、小さく始めることです。特定の投稿を表彰せずにバッジを付与しましょう。
[メンバーとして 20 件の「超いいね」投稿を作成しました]（タイトルは未定）から始めるのがよいでしょう。
基本的には、カスタムクエリを用いた独自の表彰方法を考えてみてください。
バッジと投稿をリンクさせる箇所で許可チェックを追加するのは複雑になるため、このアプローチはお勧めしません。
まずは小さく、簡単に始めましょう。
私たちにとっても、それは全く問題ないと思います。
これを行うための良いコツはありますか？
おそらく、ここではステップ0として、英語でどのバッジが欲しいか、バッジの名前、そして概念的な定義をスケッチすることが必要です。
わかりました、これに取り組みます！
既存のバッジクエリを確認し、badge_posts テーブルを対象とするクエリや、保護されたカテゴリからの投稿を除外する他の方法を使用しているクエリがどれか把握しました。
以下のバッジクエリは特定の投稿を対象としており、プライベートカテゴリでの活動に対しては付与されません。
一方、以下のバッジは特定の投稿をクエリせず、プライベートカテゴリでの活動に対しても付与されます。
これに似た機能は、すでに「Appreciated（20 投稿で 1 ライク）」と「Respected（100 投稿で 2 ライク）」のバッジでカバーされています。これらのクエリのバリエーションを追加することも可能です。例えば、「20 投稿で 10 ライク」などです。また、スーパー「いいね」されたトピックに対して付与されるバッジも良いアイデアでしょう。これは「Great Topics」バッジに相当するものになります。例えば、ユーザーが 10 件のトピックを作成し、それぞれが 10 ライクを獲得した場合に付与されるように設定できます。
特定の投稿やトピックに対する活動に対して、その投稿へのリンクを持たないバッジを追加することは意味があるでしょうか。例えば、以下の SQL を使用して「First Like」の代替バッジを作成することも考えられます。
SELECT pa1.user_id, pa1.created_at granted_at
FROM (
SELECT pa.user_id, min(pa.id) id
FROM post_actions pa
JOIN posts p on p.id = pa.post_id
WHERE post_action_type_id = 2
GROUP BY pa.user_id
) x
JOIN post_actions pa1 on pa1.id = x.id
このクエリを機能させるには、「投稿へのユーザーアクション時」ではなく「毎日更新」トリガーを使用する必要があります。バッジページでは、バッジが付与されたユーザーとその付与時刻が表示されますが、バッジの対象となった投稿へのリンクは表示されません。
このアプローチは、主に保護されたカテゴリを持つサイトにとって意味があるでしょうか？もしそうであれば、現在 badge_posts テーブルを対象としているクエリの一部を複製するために活用できるかもしれません。
これは素晴らしい一歩だと思います！
この件について再度ご連絡いたしました。
このような実装についてご意見はございますか？
思い出させてくれてありがとう！保護されたカテゴリの投稿を公開しない、役に立つバッジのリストを作成し始めます。
当社のフォーラムは当初「ログイン必須」として開始し、最近いくつかの公開カテゴリを追加しましたが、既存のカテゴリには trust_level_0 からのアクセスのみを制限するように設定しました。
そのため、既存ユーザーにとってフォーラムへのアクセス方法に変わりはなかったものの、上記のリストにあるバッジはすべて剥奪されてしまいました。当社のフォーラムは規模が小さいですが、ユーザーから寄せられた反応を見ると、バッジシステム全体が壊れているように感じられていることは明らかです。この設定では、実質的にバッジシステムを無効化するしかない状況です。
カテゴリを制限するオプションを選択した場合、既存のバッジが剥奪されることを、設定画面のどこかでより明確に伝える必要があると思います。当社にとっては、これが突然の出来事でした。
より一般的に言えば、優先順位が理解できません。カテゴリの権限設定もバッジシステムも、Discourse の中核機能として紹介されていますが、現状では両方を併用するのはほぼ不可能です。一般にアクセス可能な投稿にのみバッジを表示する利点は、他のユーザーがどの投稿に対してバッジが付与されたかを確認できることにあるのでしょうか？私には、それほどの重要な機能とは思えません。むしろ、これらの目に見えるリンクを削除し、関連する投稿を各ユーザーが自分のバッジページでだけ確認できるようにする方がよいのではないでしょうか？
うっ！OK、これは、プライベートスペースが多いコミュニティでは、バッジのインフラストラクチャ全体がかなり役に立たないことを意味しますね…
それに賛成です。
ほとんどプライベートなコミュニティでバッジを実用的にするためのプラグインや新しい設定（過去6年間で）はありますか？
これを最初から改善することに賛成です。
このトピックは長年静かでしたが、他の場所でも同様の変更を求める声を耳にしました。
必要な特定の変更を整理し、他の優先事項の中でそれがどこに位置するかを把握するだけです。
これは、オープン（公開）スペースとクローズド（さまざまな程度の「プライベート」）スペース、およびプライベートメッセージの間でコミュニティメンバーのオリエンテーションを促進することについて、別のトピックで取り上げられたことに関連しているようです。
ウェブの半公開的な性質と半重複するオーディエンスに対処することは、オンラインソーシャル世界における大きな課題です。それは直感的ではありません。ほとんどのコミュニティは、そのさまざまな部分がどれだけ公開/プライベートであるかを人々が理解できるようにする方法を模索することになります。Discourseが、ほとんどのコミュニティにとってこの公開とプライベートの混合がデフォルトになると仮定し、コミュニティメンバーがそれをナビゲートするのをどのように促進できるかを見てみるのは理にかなっているかもしれません。
この会話には初めて参加しますが、バッジ設定の下にトグルがあれば最も簡単だと思います。デフォルトではオフにしておき、チェックを入れるとエンゲージメントバッジのためにすべてのボード（プライベートを含む）に対してクエリを実行するようにします。
プラグイン/コンポーネントが使用できるフックとして開かれたままにしておけば、後でバッジをカウントするカテゴリごとの権限を与えるコンポーネントが登場する可能性があります。
