これは Feature - Dev トピックのようなものですが、どちらに含めるべきか分かりません。
プラグインでサイト設定を変更する方法はありますか？ 99% ないと思いますが、確認したいだけです。
もしない場合、イミュータブルにしないように提案を出すことはできますか？ あるいは、SiteSettings のイミュータブルなプロパティを「アンロック」するための API や方法を持つことはできますか？
私が検討している可能性のあるユースケースは、保護されたカテゴリのリストを設定に含めることで、管理者がそれらを簡単に追加/除外できるようにすることです。
ありがとうございます。
サイト設定の値を変更したいだけですか？単に SiteSetting.whatever='new value を実行するだけでよいです。それとも、それらについて何かを変更したいのですか？
それのために設定を追加するだけではだめですか？config/settings.yml に追加するだけでは？例えば、次のような感じです。
[quote=“NateDhaliwal, post:1, topic:389676”]保護されたカテゴリのリストを設定に含めることで、管理者がそれらを簡単に追加/除外できるようにする、考えられるユースケースです。
[/quote]
まずここから始めて、外側から内側へと進めましょう。
まず、コミュニティの視点からユースケースを説明していただけますか？彼らは何を達成しようとしていて、現在それを難しくしている要因は何ですか？彼らのニーズをより効果的に解決すると想像する機能は何ですか（実装方法に関係なく）？
それから、これがプラグインで実装するのが最適か、それともコア機能として実装するのが最適かを判断するために、そこから進めましょう。
その後、実装方法に関する提案について話し合うために、そこから進めましょう。
@mcwumbly @pfaffman 教えていただきありがとうございます
TCでは設定がイミュータブル（不変）であるため、Rubyのプラグインでも同様であると誤解していました。試してみます。
TCで編集可能にできると良いでしょう。私のユースケース（現在プラグインを使用しています）は、デフォルトですべてのカテゴリのすべてのトピックと投稿を取得し、何らかの処理を行うことですが、保護されたカテゴリ（excluded_categories設定のようなもの）を含めたくありません。
しかし、設定に保護されたカテゴリを追加し、その後でアクセスできれば、より簡単になります。こうすれば、管理者は設定から削除することで、含めたい保護されたカテゴリを追加できます。
@pfaffman のアイデアで、おそらく可能でしょうが、TCではできません。
この問題は、保護されたカテゴリを事前に知らないことです。
管理者としてログインしている場合、テーマコンポーネントはAPI経由でsiteSettingsを変更できます。
それなら、テーマコンポーネントの設定を作成し、それらのカテゴリを追加するだけですか？私が気づいていない保護されたprotected_categoriesサイト設定のことを言っているのではありませんよね？つまり、このようなことですか？
もっと詳しく知りたいです。このリクエストをより良い文脈で提示するのに役立つと思います。
あなたのコミュニティ自体について、もっと教えていただけますか？
この機能の主なユーザーはあなたですか、それともチームの他のメンバーも必要としていますか？この機能に依存するワークフローに関するユーザー向けのドキュメントはありますか？もしあれば、どのようなものですか？もしなければ、それがどのようなものになるか簡単に説明していただけますか？
@mcwumbly @pfaffman はい、できるだけ詳しく説明させてください。
トピックと投稿を取得し、それらをMarkdownファイルとしてGitHubに発行する（アーカイブのようなもの）プラグインを開発しています。
しかし、プライベートなカテゴリ（今ではそれが正しい用語だと思いますか？）は「プライベート」なので、これに含めたくありません。
そのため、default パラメータ内では定義できないプライベートカテゴリのリストで設定を事前に入力する方法を探しています。なぜなら、事前にプライベートカテゴリが何であるかを知ることができないからです。
これがRubyで直接 SiteSetting を変更することで可能である場合、Theme Componentの settings で同じことを行うことはできますか？後者は不変であると確信しています。Theme Component内でそれを変更する方法はありますか？
しばらくお待ちください。
コミュニティチームの視点から、あなたが解決しようとしている問題について、もう少し理解したいと思っています。
これはどのような種類のコミュニティですか？誰が運営しているのですか？なぜ彼らはコンテンツをGitHubに複製したいのですか？
彼らはどのような問題を解決しようとしているのでしょうか？
コミュニティについてというわけではありません。私は独自のやり方でこれ（バックフィルジョブも伴って）を試みています。これにより、各トピックと投稿がリポジトリ内のMarkdownファイルとして保存されます。
プライベートがあなたにとって何を意味するのか、まだわかりません。誰もが見えるカテゴリ、または匿名ユーザーが見えるカテゴリを意味しますか？それとも、何か別の定義がありますか？
それらが必要な場合は、プラグインでそれらを取得できます。おそらく、ユーザーを渡す検索（またはガーディアンを呼び出すなど）によって、または単に権限を確認することによって。
あるいは、プライベートが意見である場合、設定を追加できます。
そして、おそらく毎日実行されるジョブなどでこれを行いたいのでしょう？
GitHubにプッシュしているのであれば、ブラウザでデータをディスコースに送信するのではなく、ディスコースに実行させたいのではないでしょうか？テーマコンポーネントでどのように、またなぜそれを実行するのかわかりません。
つまり、Staff のようなグループによって制限されるカテゴリのことです。プラグインで可能なのだと思いますが、その場合、TC（トピックコントロール）の設定は変更できないということでしょうか？
さらに別の可能性として、プラグインやテーマコンポーネントとして行うのではなく、これをさらに外部化するというアプローチがあります。
関連する先行事例はこちらです: Discourse Public Data Dump
繰り返しますが、目指している最終結果の観点から可能な限りアプローチすることで、アドバイスがしやすくなると思います。
ですので、このリンクを共有していただきありがとうございます:
おそらく、これを足がかりとして、これまでに暗黙的に定義された機能仕様をさらに明確にすることができます。
現時点での私の理解では、あなたは以下を望んでいるようです:
そして、現在検討している設計は以下の通りです:
これで合っていますか？
完全に的確です！その基本的な構造をこちらに作成しました。
それには設定は必要ありません。その情報はすでにプラグインで利用可能です。
私が「プライベート」カテゴリを取得するために Category.where(...) メソッドを参照していると理解するのは正しいですか？しかし、管理者がそれらのカテゴリのいくつかを含めたい場合はどうでしょうか？コードで定義されている「プライベート」カテゴリを打ち消すために include categories のような設定が必要になりますか？それは逆効果になるでしょうか？
更新：SiteSettings はプラグイン経由で編集できるとのことです。TC設定はまだ編集できないと認識していますが、正しいでしょうか？解決策として Modify SiteSettings/make SiteSettings mutable? - #2 by pfaffman をマークします。
まだ理解できません。はい、それらの設定を SiteSetting に追加でき、プラグインはその設定を読み取ったり、変更したりすることもできます。しかし、上記のシナリオを考えると、なぜその設定を変更する必要があるのでしょうか？
もしカテゴリが A、B、C、D、E の 5 つあるとします。ここで、B と C は一部のグループでのみ利用可能だとします。リポジトリにアップロードされたときにプライベートなトピックが共有されるのを防ぐため、B と C は #staff のような他のカテゴリとともに excluded_categories 設定に追加されます。
ここでサイト管理者が B のトピックが共有されることに問題がない場合、C はそのまま残しつつ、B を設定から削除することができます。
したがって、プライベートカテゴリである B と C を追加するために、excluded_categories を最初に変更する必要があります。これで意味が通じるでしょうか？
技術的には完全に可能ですが、特に「開始時」を定義/検出するのが難しく、サイト管理者が削除した後もプラグインがBを追加し続けるのを避けたいという点から、そのアプローチは過度に複雑になると考えられます。また、新しいプライベートカテゴリが追加された場合、プラグインはそれを追加する必要がありますが、新しいカテゴリ（追加）と管理者が以前に削除したカテゴリ（再追加しない）とを区別できる必要があります。
代わりに、空で始まるinclude_private_categories設定を採用することをお勧めします。これにより、プラグインはすべてのパブリックカテゴリとinclude_private_categories内のカテゴリを処理するだけで済みます。これにより、頭痛の種が大幅に減るでしょう。
トピックのタイトルも、このトピックが本当に何についてのものかをよりよく表すように更新しました。
ここで考えられる別の設計案として、公開コンテンツ用のリポジトリと非公開コンテンツ用のリポジトリの2つを分ける方法があります。
非公開コンテンツのリポジトリ自体は非公開にしておくことができます（誰がそれにアクセスできるかを独立して決定できます）。