これは素晴らしい機能だと思いますが、現在の実装はかなり基本的なものです。フォームデザインの欠けている機能のほとんどは、このスレッドで他のユーザーによってすでに投稿されているため、データプライバシー/管理にもっと焦点を当てたいと思います。
私のコミュニティは、アプリケーションフォームを主にユーザー管理システムとして使用したいと考えています。その目的のために、フォームは、管理者が誰がアプリケーションを表示でき、誰が応答できるかを決定できるフラグシステムと同様に機能することが望ましいです。そうでなければ、現在のフォーラムテンプレートを使用すると、新規ユーザーの個人情報が公開フォーラムカテゴリに表示されることになり、望ましくありません。また、これらのフォームをユーザーグループ管理に結び付けることができれば素晴らしいでしょう。たとえば、新しいメンバーがコミュニティへの参加を申請し、モデレーターがその申請を承認した場合、自動的に信頼レベルx、ユーザーグループyを獲得し、ユーザーグループzを失うべきです。
例として、Discourseネイティブになれば素晴らしいと思われる機能がいくつかあります。discord bot Appy。現在、discord bot Appyを使用していますが、すべてを同期させるために管理者とモデレーターに追加の作業負荷がかかっています。
「いいね!」 2
sunjam
(james.network)
2
変更する必要があるのは、カテゴリを一般公開するのをやめ、グループで制限することだけです。
それは私にとって十分な解決策ではありません。これは、すべての新規採用者が他の採用者のアプリケーションを確認できるようになり、個人情報(メールアドレス、年齢など)が本来あるべきよりもはるかに多く表示されることを意味します。
そのため、アプリケーションフォームがフラグシステムのように機能することを要求します。新規ユーザーが入力を作成できますが、スタッフ(管理者、モデレーター、選択されたユーザーグループ)のみがそれらの入力を実際にアクセスできます。
編集:これが機能する1つの方法は、トピックの作成者のみが自分のトピックを表示できるカテゴリ設定がある場合です。
グループメッセージングの方が適しているかもしれません。つまり、アプリケーションはカテゴリにトピックを作成するのではなく、グループにメッセージを送信することで行われ、そのグループのメンバー(および送信者)のみがメッセージを表示できます。
残念ながら、グループメッセージング用のフォームテンプレートは利用できません。サポートに関する問い合わせの文脈でこのことについて尋ねたことがありますが、誰かが尋ねていたのですが、将来的に予定されていることなのかどうかはわかりません。
これは他のトピックでも議論されています。例えば、Offering "private support" as part of a public support community の #4(およびその後の返信)では、グループメッセージングで既に利用可能なものに対して、カテゴリ権限に多くの複雑さを追加することになるため、彼らはそれをやりたくないという印象でした。
また、グループメッセージングの方が柔軟性があり、参加者を必要に応じて追加/削除できます。例えば、技術職の採用を行う場合、アプリケーションは人事グループに送信され、人事グループがアプリケーションの基本的なチェックを完了したら、関連する技術グループを参加者として追加できます。
このようなシナリオのために、最終的にはフォームテンプレートがグループメッセージングに拡張されることを強く望んでいます。
「いいね!」 2
sunjam
(james.network)
5
カスタムウィザードはこのニーズに適している可能性があります。
「いいね!」 1
pfaffman
(Jay Pfaffman)
6
カスタムユーザーフィールドは、実際にはユーザーレコードにアタッチされているため、説明されているものにより適しているようです。
「いいね!」 2
残念ながら、それでは当社のニーズを完全に満たすことはできません。以下のような従来のアプリケーションフォームの機能が必要だからです。
- ドロップダウンメニュー
- 複数選択式の回答
- 書式設定ツール
- 条件付きフィールド(質問Aへの回答がBの場合、フィールドCを表示する)
- モデレーター/管理者が申請内容を確認できる機能
- モデレーター/管理者が変更される可能性を考慮した申請内容の長期保存(そのため、スタッフチームへの参加・離脱があるため、グループメッセージングも当社には適しません)
- 適切なデータプライバシー(つまり、ユーザーは自身の申請内容のみ閲覧できるべきです)
- 自動化されたユーザー管理(申請Aが承認された場合、ユーザーグループBを付与し、かつ/またはユーザーグループCを削除する)
短期的な解決策としては、管理者がチェックできる「ユーザーは自身のトピックのみ閲覧可能」という新しいカテゴリ設定を導入することだと思います。これにより、実験的なフォームテンプレートを特定のユーザーグループのすべてのユーザーに表示することなく使用できるため、上記のほとんどの点がカバーされます。その後、他の投稿者や私が言及した残りの機能は、開発者によって時間とともにフォームに追加される可能性があります。
以前Custom Wizardを試しましたが、管理セクションのデフォルトのDiscourse設定フィールドの一部が何らかの理由で破損しました。その後、プラグインを無効にしたところ、Discourseの設定フィールドは正常に機能するようになりました。おそらく、当時のDiscourseの最新バージョンとの互換性がなかったのでしょう。
「いいね!」 1
ありがとうございます!このサードパーティ製プラグインについては知りませんでした(Custom Wizardで問題が発生して以来、公式プラグインのみを使用しています)。
試してみます! 
「いいね!」 4
sunjam
(james.network)
10
ちなみに、これらの問題を報告すると、開発者にとって役立つでしょう。時間があれば、やる価値はあると思います。
「いいね!」 1
Heliosurge
(Dan DeMontmorency)
11
pavilions (plugins) の更新には、推奨されるスケジュールがあります。
「いいね!」 1