サイト全体の AI 統合を無効にしたかったのですが、それが単一の設定でできることに非常に満足しています。OP が求めている答えは、discourse_ai_enabled のユーザー単位版のようなものかもしれません。そうすれば、AI はサイト全体で完全にオン/オフになるわけではありません。サイトレベルで有効になっている AI 機能であっても、ユーザー単位で抑制できるのです。discourse_ai_enabled のロジックは、サイト全体で true かつユーザー単位でも true となります。
一般的に、不要な複雑さを避けるために新しいカスタマイズ設定を追加することを彼らは考えているのは事実ですが、AI は設定可能な項目数が最も多い機能です。AI が存在するようになったごく短い期間の間に、Discourse において最もカスタマイズ性の高い機能になっているようです。[1]
以下は、手っ取り早い分析です。私はここに来たばかりなので、もし間違いがあれば確認できるように計算過程を示します。
su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt
これが正しい数え方であれば、可能なサイト設定は 1663 件です。そのうち、104 件が ai_ で始まり、3 つの AI 設定はそうではありません（composer_ai_helper_allowed_groups、discourse_ai_enabled、post_ai_helper_allowed_groups）。つまり、私の計算では、AI は圧倒的にカスタム設定の最大のグループを占めています（1663 件中 107 件、つまり全サイト設定の 6.4%）。以下は上位 10 件です。
- 107 ai
- 84 discourse
- 83 chat
- 71 max
- 65 enable
- 48 default
- 30 dfp
- 28 oauth2
- 28 amazon
- 28 allow
一方、AI 機能のユーザー単位での抑制は、1663 件のうちの 1 件に過ぎません。他方、多くのコードパスがサイト全体でチェックしている場合、ユーザー単位でチェックするのは難しいかもしれません。これは、私が推測する資格がないトレードオフです。
また、比較的明確に定義され、自己完結型の機能であり、比較的新しいため、
ai_という命名規則が一貫しているおかげで、他のコンポーネントよりも設定項目を数えやすいのです。だからこそ、これは「手っ取り早い（quick and dirty）」分析だと言っているのです。 ↩︎