皆さん、こんにちは。適切な場所に投稿していることを願っています。新しいDiscourseウェブサイト用のプラグインを開発しようとしています。
例のリポジトリこちら をフォークし、Plugin Outletを機能させましたが、行き詰まってしまい、迷子になり混乱しています。最近、LaravelのようなMVC PHPフレームワークに慣れてきましたが、JSフレームワークには非常に新しいです。Ruby、Rails、Emberには触れたことがありません。
私のウェブサイトはHOAコミュニティ用です。やりたいことは、ユーザーごとに いくつかの追加フィールドのデータを収集して保存することです。
legal_name (文字列)is_owner (ブール値)is_resident (ブール値)building (文字列) - 建物番号を表しますunit (文字列) - ユニット番号を表します…および、モデレーターが確認したかどうかなどの、いくつかの内部変数。
これらのフィールドをユーザーサインアップに必須にしたいと考えています。つまり、ユーザーサインアップフォームを変更する必要があります。create-account-after-passwordアウトレットにフックして、追加フィールドを表示させましたが、明らかにこれは機能しません。
app/assets/javascripts/discourse/app/controllers/create-account.jsのコントローラーを拡張する必要があると考えています。これは、送信時に新しいフォーム値を取得するためだけでなく、サイト名this.siteSettings.titleをclient.en.yml翻訳フィールドで使用するためだけでも（これは明白に良くありません）。（現在、サインアップフォームの追加フィールドには、「あなたの[%{title}値が見つかりません]とのつながりは何ですか？」という見出しが付いています。）
答えを探そうとすればするほど、さらに多くの疑問が生じ、それらは大きくなっていきました。私が従おうとしたさまざまなガイドは、異なるバージョンのDiscourse用に書かれていたようです。例のプラグインリポジトリには、理解できないものがあります。クライアントサイドルートとサーバーサイドルートの違いは何ですか？プラグインとモジュールの違いは何ですか？私は完全に迷っています。
どなたか助けていただけたら、非常に感謝します。よろしくお願いします。
「いいね！」 2
Moin
2023 年 5 月 28 日午前 3:46
2
「いいね！」 3
ありがとうございます。私が望むすべての機能を提供するものではありませんが、その機能が私の目標達成に役立つかどうかを検討するきっかけにはなりました。
いずれにしても、プラグインを使用して既存のコントローラーを拡張する方法という元の質問に答える必要があると思います。そのようなことは可能でしょうか？
Lilly
2023 年 5 月 28 日午前 4:38
4
それを保存してどこかに表示するのですか？このデータで何をしたいのですか？フォーラムのどこかに表示するだけでなく、他の機能のために保存したいのだと理解していますが。
RGJ
2023 年 5 月 28 日午前 5:56
6
「いいね！」 3
「このデータで何をしたいのですか？フォーラムのどこかに表示するだけでなく、他の機能のために保存したいのだと思いますが。」
私の究極の希望/ビジョンは次のとおりでした。
コミュニティ内の各ユニットの所有者に、そのユニットの居住者のみに対するモデレーター権限を付与します。
私たちのコミュニティには約200のユニットがあることを考慮すると、これを達成するためにグループ機能を使用するのは現実的ではないように思えました。グループは、以下の＃3とも競合します。
私の理想的なUXは、サインアップフォームの「ユニット」のドロップダウンメニューが、「建物」フィールドでのユーザーの選択に動的に反応し、その建物にあるユニットのみを提供するというものでした。（Discourseの初期化時にJSON設定ファイルを解析する方法を見つけるつもりでした。）
各ユーザーに、自分のユニット以外のユーザーから建物の番号やユニット番号を非表示にするかどうかを選択できるようにしたかったのです。
コアのカスタムフィールド機能は、このオプションをフィールドごと（ユーザーごとではなく）、また 管理者のみに提供し、ユーザー自身には提供しないという印象を持っています。
これは「 icing on the cake」のようなものですが、「所有者: はい」のように表示する代わりに、システムにこれらのフィールドに関する特別な知識を持たせ、ユーザーの概要でそれらを異なる方法でスタイル設定したかったのです。SVGの権利証アイコンや、モデレーターがステータスを確認したかどうかを示すチェックマーク（または居住者を示す家のアイコン）などを表示します。そのようなものです。
もしかしたら私はここで picky すぎるのかもしれませんが、コア機能を達成するための学習曲線を超えれば、小さなウィッシュリスト項目はほとんど些細なことになると感じています。
私のコミュニティの多くの居住者は、コンピューターの知識がほとんどまたは全くない高齢者です。一部の居住者が、アドレスのプライバシーや建物/ユニット番号の検証されていない入力といった実際の使用上の問題だけでなく、単に新しいという理由だけで、Facebookではない私のDiscourseウェブサイトを採用して利用することを望まないのではないかと深刻に懸念しています。
「いいね！」 2
RGJ
2023 年 5 月 28 日午前 8:12
9
グループはその目的に対してうまく機能し、簡単に200のグループを持つことができます。Pavilionのカスタムウィザードプラグイン を使用することもできます。
それは真実ですが、それを公開してどこかに表示したいユーザーは、つまり「プライベート」な建物フィールドと「パブリック」な建物フィールドを持つことができます。
「いいね！」 2
pfaffman
2023 年 5 月 28 日午前 10:47
10
機能を追加する必要がある場合は、Discourse をフォークするのではなく、プラグインまたはテーマコンポーネントを作成する必要があります。
petermarkley:
サインアップ UX
テーマコンポーネントで実行できるため、プラグインは必要ありませんが、プラグインを作成している場合は、フロントエンドの変更をプラグインに含めることもできます。Discourse プラグインの開発 - パート 1 - 基本的なプラグインの作成 。同様の機能を追加するプラグインを探すことも良い方法です。例を検索するために使用できる Discourse リポジトリ all-the-plugins があります。
petermarkley:
フィールドのプライバシー設定
提案されているように、これらのフィールドの公開バージョンと非公開バージョンを持つことは良い解決策ですが、プラグインにユーザーフィールドを追加し、それらのフィールドをシリアライザーに追加して表示する方法を制御することもできます。
petermarkley:
おしゃれなスタイリング
これはテーマコンポーネントが行うことです。テーマ開発者クイックリファレンスガイド が開始点になる可能性があります。
「いいね！」 2
RGJ
2023 年 5 月 28 日午前 10:53
11
TS は Discourse をフォークするつもりはないと思いますが??
「いいね！」 3
pfaffman
2023 年 5 月 28 日午前 11:31
12
彼がリンクしたリポジトリはプラグインではなく、フォークのようです。
「いいね！」 2
RGJ
2023 年 5 月 28 日午後 12:45
13
discourse-plugin-skeleton をフォークすることは、私にとってプラグインを作成するための良い出発点 のようです…
「いいね！」 5
pfaffman
2023 年 5 月 28 日午後 1:51
14
同意します！何を見たのか分かりません！それがフォークであることを見落としたことが分かりません。
plugin.rbを探したと思っていました…。
「いいね！」 2
明確にしてくれてありがとう、@RGJ ！
「プラグインでユーザーフィールドを追加し、それらをシリアライザーに追加するかどうか、またどのように追加するかを制御することもできます。」
これは、「アカウント作成」モーダルフォームに追加し、必須にすることも含まれますか？これを行う方法の例やガイドを教えていただけますか？
すでにリンクされている「Discourse プラグインの開発」のガイド全体を読みました。そこから始めました。結局、拡張する方法を示す実際の機能は、紫色の触手を持つ新しい管理者ページを作成する ことだけです。すでにプラグインの管理者ページは動作していますが、必要かどうかさえわかりません。現在の問題とは関係がないため、彼らの例は私のケースにはあまり役立ちません。
「いいね！」 2
グループはその目的に対してうまく機能し、簡単に200個のグループを持つことができます。
実際には、すべての順列（各ユニットのオーナー、居住者、またはアフィリエイト）をカバーするには400から600の間になります。しかし、それはどのように機能するのでしょうか？200個のグループすべてがユーザーに同一に表示され、「オーナー187」ではなく単に「オーナー」と表示されるのでしょうか？
これはより細かい質問ですが、内部グループIDはエンドユーザーにどこかで、例えばURLなどで公開されますか？ユーザーが自分のユニット番号を非公開に設定した場合、他のユーザーのグループIDと比較することでそれを特定できますか？
私としては、3つのグループ（オーナー、居住者、アフィリエイト、または単に2つ：オーナーと居住者）を作成する方が良い結果が得られるかもしれません。その後、ユーザーが間違ったユニットの居住者をモデレートしようとしている場合に、それらのグループを適切に割り当て、特定のアクションをブロックできるのではないでしょうか？
そのようなアクションをブロックすることが完全に不可能である場合、600個のグループを作成することになり、ユーザーがシステムを「ハック」して誰かの個人情報をさらすような賢いアイデアを思いつかないことを願うだけです。
pfaffman
2023 年 5 月 28 日午後 6:21
19
待って。何だって？つまり、私が賃借人でフォーラムで何かを言ったら、大家が私の言葉を変えられるということか？トピックは単一のカテゴリによってのみ所有されるため、所有者とテナントだけの会話になるだろう。
それは理にかなっていない。そして、トピックレベルの権限を持つ簡単な方法はない。
建物ごとのグループやカテゴリが欲しいと思うだろうが、ユニットごとの制御は意味をなさない。
トピックレベルの権限については何も言っていません。
「モデレーター」という言葉が間違っているのかもしれませんね。わかりません。（私はこれまでDiscourseを使ったことがありません。）
私が話しているのは、ユーザーごと にフォーラムへのアクセスを承認または削除することです。ですから、あなたの家主はあなたの言葉を変えることはできませんが、あなたが住民としてサインアップを確認する権限を持ち、あなたが荒らしになった場合は、ミュートまたは禁止することができます。投稿やトピックは、ウェブサイトのスタッフによって、コンテンツポリシーに対して平等にモデレートされます。所有者によってではありません。
私の目標は、フォーラムへのアクセスを、各物件自体の法的な権限の連鎖にできるだけ結びつけることです。ここで物件を法的に所有している確認済みの所有者は決して禁止されるべきではありませんが、ポリシーに違反する投稿をした場合、その投稿はスタッフによって削除される可能性があります。しかし、物件を売却した場合、彼らの「所有者」ステータスは直ちに剥奪され、ウェブサイトから削除される可能性があります（新しい物件所有者によって承認された「アフィリエイト」ステータスを希望しない限り）。
私たちのコミュニティでは、同じ建物内のユニットがお互いに関連している関係はありません。物理的に接続されているという事実以外は。それだけです。建物ごとに人々をグループ化することは、ほとんど化粧的なUX上の決定です。建物全体に権限を持つ人を任命することは、ここでは意味がありません。
これを見つけました: Add a custom per-user setting in a plugin
コメントで、あるユーザーが「コントローラーをパッチした」と言っていました。彼は assets/javascripts/discourse/initializers/ に .js.es6 ファイルを持っており、api.modifyClass() というメソッドを参照しています…
うーん
「いいね！」 2
pfaffman
2023 年 5 月 28 日午後 7:04
22
やった！それが一番だ！
決める前に、ディスコースに慣れておくことをお勧めします。
少数の人が参加者を承認する方が、すべてのユニット所有者がサイトへのアクセスを制御するよりも簡単だと思います。所有者が決定する場合、誰かがユニットを売却した場合はどうなりますか？その時、誰が決定しますか？フォーラムのメンバーになりたいテナントに関心のない所有者はどうなりますか？コンプレックスのマネージャーに任せる方がはるかに理にかなっており、プラグインを必要としない可能性が高いと思います。
「いいね！」 1
はい、これだけのためにDiscourse自体をフォークすることは絶対にありませんでした。
何か掴んだかもしれません。