Discourseインスタンスに約20,000のグループを配置したいのですが、これは可能でしょうか。また、ウェブサイトのパフォーマンスに影響はありますか？
「いいね！」 2
ユーザーは何人になりますか？
20,000グループは何の問題を解決しますか？
「いいね！」 2
シナリオは以下の通りです。研究論文の議論プラットフォームを実現するためにDiscourseを使用しています。各論文は論文IDを持つタグで表されます。そのタグの下に作成されたすべてのトピックは、その論文のタグページに表示されます。
問題は、以下の機能が欠けていることです。
システムにアップロードされた論文の著者に対して、手動の承認プロセスがあります。著者に、自分の論文にタグ付けされた投稿を編集する能力を与えたいと考えています。しかし、タグに基づいて権限を与えることはできないことを学びました。
そこで、論文ごとにグループを作成するというアイデアを思いつきました。論文の著者は同じグループに属することになります。しかし、これが私の問題を解決できるかどうかさえ定かではありません。なぜなら、特定の投稿を編集する能力をどのように与えることができるのかわからないからです。
この機能を実現するためのエレガントな方法があれば、ぜひお聞かせください。よろしくお願いします。
「いいね！」 3
著者は、自分の論文への返信であれば、他の人の投稿を編集できるようにしたいということですか？
そして、トピックではなく投稿のことですか？
はい、投稿が応答であるか、または論文に関連しているかは、現在タグによって決定されています。
ただし、役立つのであれば、論文ごとにグループを作成することもできます。
理想的には、投稿とトピックの両方を編集できるようにする必要があります。
グループは非常に軽量で、問題なく数千個まで作成できます。
一方で、カテゴリを20,000個持つとパフォーマンスの問題が発生します。
「いいね！」 10
投稿にはタグがなく、トピックにあります。
なぜ他の人の投稿を編集できるようにしたいのか理解できません。ウィキにすることはできますが、その場合誰でも編集できるようになります。
あるいは、ユーザーのトピックをウィキにして、誰でも編集できるようにしたいのかもしれません。
誰かの言葉を変えることが理にかなうモデルが何なのか、私には理解できません。
「いいね！」 2
編集がもたらすメリットについても、いくつかのシナリオを検討した後に疑問を持ち始めました。しかし、トピックに関連する論文の著者が返信しているかどうかを確認する仕組みがあれば良いのですが、グループではまだそれができないと思います。
より具体的に言うと：ユーザーがID 5の論文にタグを付けて投稿を作成したとします。論文5の著者がそのトピックに返信した場合：理想的な機能は、返信しているユーザーが議論されている論文の著者であることを（フレア、タイトル、投稿の一番上に小さなデフォルトテキストなどで）示すことでしょう。
各論文がトピックであり、トピックのOP（元の投稿者）を著者に割り当てると、OPからのさらなる返信に視覚的な差別化を追加するCSSルールを作成するのは簡単です。
「いいね！」 1
なぜペーパーごとにトピックを1つだけ設定しないのでしょうか？そうすれば混乱はありません。タグやグループは不要になります。
また、トピック（投稿の集まり）と投稿（トピック内の個人のメッセージ）というDiscourseの感覚を混同しているようです。
しかし、@falco が私より先に回答してしまいました…
「いいね！」 1
@pfaffman @falco 技術的には、各論文はタグです。その理由は、1つのトピックでは論文に関するすべての議論や質問を網羅するには不十分だからです。議論すべき多くの側面があり、このフォーラムの主な目的は、論文の周りで起こったすべての議論の単一の情報源を持つことです。したがって、各論文はタグであり、論文のタグの下に作成されたすべてのトピックは、/tag/:paper_id ページから見ることができます。
このシナリオでCSSトリックを実行することは可能ですか？必要であれば、タグとそのそれぞれの「作成者ユーザー」の関係を定義する外部データベースを作成できます。
「いいね！」 1
はい、そのデータベースを解析して自動生成されるCSSファイルを使用することができます。
カスタムプラグインを使用して、Discourse内でこれらすべてを行うこともできます。これにより、投稿作成者が一致する投稿のトピックシリアライザーに extra-field が追加され、フロントエンドアプリケーションで利用できるようになります。
「いいね！」 1
なるほど、プラグインは全くの初心者ですが、できることを試してみます。アドバイスありがとうございます！
「いいね！」 2
行き詰まったら、いつでも Dev でトピックを開いてください。
「いいね！」 1
トピックにはタグがあり、投稿にはタグがないことを理解しています。あなたは「投稿」という言葉を使っていますが、それは「トピック」を意味していると思います。
これには答えていないと思います。他人の投稿を編集できるようにしたくないのであれば、問題はないはずです。他人の投稿を編集できるようにしたい理由が思いつきませんが、もしそうしたいのであれば、ウィキにすることが解決策になるかもしれません。
特定の論文に関するトピックに、その論文のタグ（DOIのようなものですが、現時点ではDOIがない可能性もあります）を付けるというのは素晴らしいアイデアで、これはAPIを使って今すぐ実行できます。また、トピックを編集できるユーザー（trust_level 3、およびトピックのオーナー）はタグを追加できます。他のユーザーはフラグを立ててタグ付けを依頼できます（ただし、トピックを開始した人は、それがその論文に関するものであることを知らないのでしょうか？）。
現時点では、プラグインが必要な理由が明確ではありません。
パフォーマンスの問題はどこに現れるか教えていただけますか？つまり、特定のページで発生するのか、それとも一般的な問題なのかということです。各カテゴリが1つか2つのグループにリンクされており、平均的なユーザーがアクセスできるカテゴリが合計で10〜20個しかない場合、20,000個のカテゴリがあっても問題になりますか？
私の（仮説上の）ユースケースでは、グループPMを介して公開トピックを議論できるようにすることです。このアプローチは、二極化したトピックに関する生産的な公開議論を生成しようと、いくつかの異なる方法で使用できます。基本的に、特定のトピックに関連するチーム（グループ）に参加し、チームとして公開トピックに応答するためのルールセットに従うように人々を招待することで、議論をゲーム化できます。
サイトのスタッフにとって数千のグループが引き起こす可能性のあるUIの問題に対処する準備はできています。これはDiscourseグループの予期しないユースケースであることを認識しているため、見落としている明らかなパフォーマンスの問題がないか、ここに投稿しています。
「いいね！」 1
なるほど、想像していたよりもずっと分かりやすいです。 
ユーザー作成グループ機能が計画中にあると思いますが、まだ先のことだと思います。
「いいね！」 1
それは素晴らしいですが、今はAPIで可能です。
「いいね！」 1
ああ。話が逸れてきているのですが、新しいトピックごとにWebhookを受け取って、それ用のグループを作成するAPIのようなものを使えばいいかもしれません。プラグインは不要です。Discourseをそのようなサービスのどちらかの側で利用できることに、なぜ今まで気づかなかったのか。
そして今日、GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows が私の目に留まりました。これらのサービスにお金を払うのではなく、これに作業を任せることができるようです。Discourseのサポートが標準で組み込まれているかは疑問ですが、動作するようにするのは十分簡単でしょう。
「いいね！」 1