@denvergeeksさん、ありがとうございます。しかし、これは有料のサブスクリプションプランではありません。時折、メンバーから少額の寄付がある場合を除き、すべて自己負担です。
セルフホスティングですか?
@Nathankさん、ありがとうございます。
カスタムウィザードプラグインをインストールしましたが、今のところ目的どおりに動作させることはできていません。
最も関連性が高いと思われる機能は、サブスクライバー専用とマークされています。代替アプローチを却下することはできませんが、これまでのところ、ドロップダウン/マルチセレクトカスタムフィールドを介して確立されたプライベートフォーラムメンバーの資格のある特性を持つ個人を特定しながら、パブリックフォーラムの応募者として他のすべての人を除外する複雑さに対処するエレガントなソリューションはありません。
おそらく、試みる必要はないかもしれません。サインアップを承認する際に、応募者の回答に基づいてグループメンバーシップを個別に割り当てるだけかもしれません。(ただし、パブリックにとっては醜いサインアップ体験になります)
もあります
はい、おっしゃる通りです。これらの機能(特に「グループに追加」)を使用するには、無料コミュニティサブスクリプションが必要になります。これは少し手間が増えますが、それでも可能です。
@nathank さん、ありがとうございます。
無料コミュニティサブスクリプションの申請を提出しました。結果を見てみます。
いつでも「無料」ポリシーを変更する可能性のあるプラグインに永久に依存することになるのではないかと、少し不安を感じています。もしそうなった場合、代替手段はありますか?
ある程度は。サブスクリプションがいかなる理由であれ失効した場合でも、ウィザードは引き続き機能しますが、そのサブスクライバー機能への変更はロックされます。
このスレッドを遡ると、自動化が機能しなかったのは奇妙です。それは重大なバグのように思われ、再現できます。
あなたのユースケースでは、それを修正するように提唱し、カスタムウィザードプラグインを回避策と見なす方が良いかもしれません。
私のユースケースも同様です。プライベート(私の場合は有料)コミュニティを作成したいのですが、訪問者がアカウントを作成し、支払いなしで限定的な(ティーザー)コンテンツを見られるようにしたいのです。(匿名アクセスは許可しないため、「ログイン必須」に設定しました。)
すべてが解決したら、@Paul_King さん、最終的に使用したプラグイン、自動化や検証などを含む設定、そして注意点などをまとめていただけますでしょうか? 事前に感謝いたします。
@nathank さん、訪問者グループと(有料の)メンバーグループがある場合、「全員」のセキュリティ設定を変更するだけでカテゴリへのアクセスを制限できる、ということで合っていますか? (そして、すべてのサブカテゴリも注意深く確認する必要があります。セキュリティ設定は継承されないためです。これは昨日学んだことで、直感的ではなく、潜在的に危険でした! https://meta.discourse.org/t/subcategory-does-not-inherit-security-settings/101122)特に、訪問者の信頼レベルは、自分でアクセス権を付与できるようになるまで上昇しないということでよろしいでしょうか?
また、@nathank さん、これはどういう意味ですか?
メンバーが、セキュリティが(完全に、つまりメンバー向けに)制限されている別のメンバーカテゴリに、まったくクロスリンクできないということでしょうか? それはかなりの代償です!
リードを獲得するために、ログインした訪問者を許可しようとすることが本当に価値があるかどうか、現時点で再考しています。
@denvergeeks さん、私のコミュニティは有料なので、ホスティングをアップグレードして Discourse Subscriptions プラグインにアクセスできるかもしれません。ThriveCart を使用する予定です。私のコース(任意、コミュニティ外)はすでにそこで有料で販売されているため、コース、コーチング、コミュニティメンバーシップなどをバンドルして、すべての金銭取引を1か所にまとめることができます。
はい、その通りです。
サブカテゴリへのアクセス権を付与するには、グループが親カテゴリへのアクセス権も持っている必要があります。これにより、あなたが指摘している危険からうまく保護されます。
それほど悪くはありません。リンクは問題なくできますが、素敵なワンボックスは生成されません。
残念ながら、標準ではStripeとのみ統合されています。そうでなければ、あなたにとって理想的でしょう。
@nathank ありがとうございます。バグとして報告しました。
その間、私のプロセスの大部分は、すべての既存ユーザーがプライベートフォーラムの「プライベートフォーラム」グループメンバーシップを自動的に割り当てられることを必要とします(これまでは、グループを明示的に使用しておらず、フォーラムはデフォルトでプライベートでした)。招待を(冗長に)送信することを含まない方法でこれを達成する方法が見当たりません。アクセスを維持するためだけに、すべての既存のフォーラムユーザーが応答する必要があります。
これを自動的に達成する唯一の方法は、厄介なデータエクスプローラークエリを経由することであるという、ひどい嫌な予感がします。
はい、Digital Oceanでセルフホスティングしています
沈む必要はありません!
ユーザー名またはメールアドレスのリスト(たとえば、/admin/usersからのエクスポート)がある場合は、グループページの
の部分にコピー&ペーストするだけで済みます。
楽勝です!
記憶が正しければ、1000人以上のユーザーがいると苦労します。しかし、大丈夫なはずです。
@nathank さん、ありがとうございます。
ダイアログを見ると、そのように書かれていると、それらのユーザーを実際に移動させるのではなく、単に招待するだけのように読めますか?
既存のアカウントを持つユーザーを追加し、持たないユーザーには招待を送信するのは賢いですね。
私がリクエストしたので知っています!でも、コピーはもっと良くできたかもしれませんね?
テストユーザー数名で試してみてください。
Nathan様、ありがとうございます。おっしゃる通りに動作し、非常に巧妙ですね!
Excelからクリーニングされたメールアドレスの列をダイアログに貼り付けたところ、Windowsのクリップボードコピーをカンマ区切りとして認識しました。
私の場合は、「Error 502」が頻繁に発生しました。一度に500ユーザーしか貼り付けなくてもです。これはサーバーのボトルネックの問題のようです(私のホスティングプランではネットワークとCPU使用率に制限があります)。
一度に200ユーザーに減らすと、ほぼ一貫して機能しましたが、バッチ間の時間を長く取れば、一度に少し多めに貼り付けることができました。
次のステップは、「プライベートフォーラム」のカスタムユーザーフィールド変数と、グループ「プライベートフォーラム」へのアクセスを実装または防止する双方向同期リンクを何らかの方法で取得することです。Discourse Automation経由ではまだうまくいっていません。
現在、サインアップ時に「パブリックフォーラム」のみをチェックしたテストアカウントは、両方に完全にアクセスできてしまいます。
パブリックフォーラムとプライベートフォーラムへのアクセスに関する私の新しいカスタムユーザーフィールドは、ユーザープロファイルにも表示されるため、特に既存ユーザーのこれらのフィールドが空の場合、混乱の原因となる可能性があります。
フィールドを管理者のみに表示するか、パブリックフォーラム専用ユーザーの場合はグレーアウトする方が良いかもしれません。
管理者が、フォーラム管理者が直接、アクセス可能なユーザーグループ(複数可)を指名または上書きできるようにし、それによってユーザーに割り当てられたカテゴリを、すべて同じ「ユーザーの承認」ダイアログから行えるようになると、非常に役立ちます。
実際、ユーザープロファイル全体をこのダイアログから編集できるようにすると、カスタムユーザーフィールドで特定されたユーザーのエラーをクリーンアップできるようになります。
現在、サインアップ時にプロファイルの問題を整理する唯一の方法は、ユーザーを承認することに加えて、他の領域に何度も移動する必要があり、その結果、管理者によるエラーや見落としのリスクが大幅に高まります。
OK、アップデートのお知らせです。
ついにDiscourse Automationを動作させることができました。コツは、最初に試したチェックボックスフィールドタイプではなく、ドロップダウンカスタムユーザーフィールドタイプを使用することでした(指示には明記されていませんが)。ドロップダウンのオプションは、完全なユーザーグループ名と正確に対応している必要があります。
非常に重要です。この新しいフィールドは、サインアップ後にユーザーが編集できないようにしてください。そうしないと、パブリックフォーラムへの参加のみが承認されたユーザーが、後で一方的にプライベートフォーラムへのアクセス権を自身に付与できてしまいます。
Hi @tgustilo
I seem to have gotten things working without recourse to any 3rd party plugins.
The built-in Automations plugin is the only one I am using, and a tip & a gotcha for this was posted just above in this thread.
I have (for now) given up on a conditional signup user dialog where the info a user is asked to provide differs depending on the forum they want to access. So no Discourse Authentication Validations or Custom Wizard Plugin
The result is not quite as elegant for public forum applicants, but to some extent there is probably utility in exposing most of the professional qualifications and working role etc custom user fields used for private forum applicants anyway, to capture any other professional qualifications and roles the applying member of the public holds, and displaying this on their public profile.
This info means anyone engaging with this person has a greater sense of what might be relevant to their level and area of expertise.
From here, I would really like a way for an administrator to be able to directly edit a user application before it is approved - all from the same approval dialog
That way someone attempting to apply for access to the private forum who clearly doesn’t belong (based on the other info provided), can at least be granted membership of the public forum user group without having to re-apply from scratch (wasting that effort), and any other obvious mistakes could be corrected in one hit (Perhaps with a color coded flag warning the user of their edited profile fields).
Right now addressing problems in submitted applicant user profiles (including the user’s selected user group) requires either rejecting the user’s application outright, with little if any detailed explanation, or undertaking a separate multi-step and error prone clean up process, with high risk of mistakes or omissions by the administrator.
@tgustilo様
サードパーティのプラグインを一切使用せずに、すべてを機能させることができたようです。
使用しているのは組み込みの「Automations」プラグインのみで、これに関するヒントと注意点は、このスレッドのすぐ上で投稿されています。
(今のところ)ユーザーがアクセスしたいフォーラムによって異なる情報が要求される条件付きサインアップユーザーダイアログは諦めました。そのため、Discourse Authentication ValidationsやCustom Wizard Pluginは使用していません。
パブリックフォーラムの申請者にとっては、それほど洗練されたものではありませんが、ある程度は、プライベートフォーラムの申請者に使用される専門資格や職務などのカスタムユーザーフィールドのほとんどを公開することに有用性があるでしょう。これにより、申請者が持つ他の専門資格や役割を捉え、公開プロフィールに表示することができます。
この情報により、その人と関わる人は、その人のレベルや専門分野に関連する可能性のあるものについて、より深く理解することができます。
ここから、管理者が承認前にユーザー申請を直接編集できる方法を本当に希望します。すべて同じ承認ダイアログから行えるようにしたいです。
そうすれば、提供された他の情報に基づいて、明らかに属していないプライベートフォーラムへのアクセスを申請しようとしている人も、最初からやり直す(その労力を無駄にする)ことなく、少なくともパブリックフォーラムのユーザーグループのメンバーシップを付与でき、その他の明らかな間違いも一度に修正できます(編集されたプロフィールフィールドについてユーザーに警告する色分けされたフラグが表示されるかもしれません)。
現在、提出された申請者のユーザープロファイル(ユーザーが選択したユーザーグループを含む)の問題に対処するには、詳細な説明がほとんどまたは全くないままユーザーの申請を完全に拒否するか、管理者の間違いや見落としの高いリスクを伴う、別個の多段階でエラーが発生しやすいクリーンアッププロセスを実行する必要があります。
私も同様の申請プロセスを、Automationプラグインのみで制御し、理想的には、あなたが言うように、承認プロセス中に申請者のグループメンバーシップ、プロフィールフィールドなどを微調整できるようにしたいと考えています。
管理者の申請と承認のワークフローは、公開メンバー(またはトライアルメンバー、無料コンテンツへのアクセスが制限されているメンバー)の処理から、プライベートメンバー、有料メンバー、またはコミットメンバーのより複雑なオンボーディングまで、複数のユースケースに対応できます。
また、優れたベータテスターや初期メンバーをフィルタリングすることも有用だと考えており、それが現在の私の課題です。興味のある人すべてに対して広範な公開オプションを用意したいのですが、多くの影響力を持つ強力な初期メンバーまたはコアメンバーになる人を実際にフィルタリングする必要があります。
コースやコーチングの提供に付随するサポートコミュニティを構築している場合、初期サインアップの自動化により、それらの人々を適切なコホートまたはコーチング/サポートグループに誘導することもできます。
したがって、自動化されたサインアップ/申請と柔軟な管理者承認を組み合わせることには多くの用途があります。
単一の公式無料プラグインを、追加料金なしで設定できることは、資金がない、または(多くの)有料メンバーシップがないスタートアップコミュニティにとって非常に役立つと同意します。
あなたのプロセスを共有していただきありがとうございます。非常に参考になりました。

