tkrunning
(Thomas K. Running)
1
みなさん、こんにちは。現在、十分にサポートされていないユースケースがあります。招待されたユーザー(リンクで招待されたユーザーも含む)のアクティベーションメールを無効にする必要があるのです。
上記のトピックを開始した後、この機能は実装されましたが、メールで招待されたユーザーにのみ適用されました。
私の Discourse インスタンスは招待制で、実際に招待リンクをメールで送信していますが、Discourse 組み込みのメール機能は使用していません。私は /invites/link への POST リクエストで招待リンクを生成し、外部データベースに保存してから、ユーザーにリンクを送信しています。そのため、ユーザーがリンクをクリックした時点ではすでにメールが確認済みですが、再度確認を求められてしまいます。
私のユースケースはあまり一般的ではないことは理解していますが、必要な動作を実現するために、Discourse の必要な部分を修正するシンプルなプラグインを作成してみようと思いました。
スケルトンは作成して動作確認済みで、サイト設定 (no_activation_enabled) も追加しました。コアリポジトリを調べてみたところ、おそらく編集が必要なのは以下のファイルではないかと考えられます。
確信はありませんが、条件分岐(SiteSetting.no_activation_enabled が有効で、かつユーザーがスタッフによって招待された場合、おそらく invite.invited_by.staff など)で user.attributes 内の active を true に変更することで動作するかもしれません。
user.attributes = {
email: invite.email,
username: available_username,
name: name || available_username,
active: false,
trust_level: SiteSetting.default_invitee_trust_level,
ip_address: ip_address,
registration_ip_address: ip_address
}
しかし、これをプラグインからどのように変更すればよいのでしょうか?そもそもプラグインの機能範囲内なのでしょうか?プラグインは機能を追加するだけで、既存のものを修正できないのでしょうか?それとも invite_redeemer.rb ファイル全体を置き換える必要があるのでしょうか?
プラグイン構築の入門編と、こちらのガイドは完了しましたが、コードベース(他のプラグインも含む)を数時間掘り下げた結果、壁に頭をぶつけているような状況です。もし何かヒントやアドバイスがあれば、大変感謝いたします!
Stephen
(Stephen)
2
外部サイトからこれを処理しているなら、SSOを処理して検証情報をペイロードに渡せばよいのでは?
tkrunning
(Thomas K. Running)
3
こんにちは、Stephen さん。ご意見ありがとうございます。
私は外部サイトのユーザーアカウントは管理していません。Airtable、Zapier、GCF(Google Cloud Functions)を連携させて ESP(メール配信サービス)などの複数のサービスを統合するマスター構成を持っていますが、メインのユーザーデータベースは Discourse です。ただ、Discourse 標準のサインアップフォームはコンバージョンに優れておらず、ブログ記事などに統合できないため、使いたくありません。むしろ、Discourse は Jekyll ベースのコンテンツサイトに対して SSO プロバイダーとして機能しており、ユーザーが Discourse にログインしているかどうかを確認するためにフェッチリクエストを送信し、それに応じてコンテンツページを調整しています。
angus
(Angus McLeod)
4
こんにちは、ようこそ 
@Stephen と同様、これが適切なツールかどうかは確信が持てませんが、十分に検討された上で選択されたと信じています。
これは何としても避けるべきです。クラスをモンスターパッチする必要がある場合でも、ほぼ常に他の解決策が存在します。Discourse におけるモンスターパッチについては、こちらをご覧ください:https://meta.discourse.org/t/tips-for-overriding-existing-discourse-methods-in-plugins/83389。
今回の場合、焦点を当てているメソッドには、すでに目的とする処理を行うコードが存在しているようです:discourse/app/models/invite_redeemer.rb at main · discourse/discourse · GitHub
問題は、生成した招待コードに正しい emailed_status_type が設定されていないため、その条件が満たされていないことです。解決策としては、最初から異なる招待コードを生成することだと考えられます。そこが注力すべきポイントです。
riking
(Kane York)
5
これは本質的に、コアから削除された機能(危険すぎるため)を再導入するものです。もしこれらの招待トークンを誤って扱えば、意図された受信者が使用する前にそれらを盗んだ人物が、受信者としてフォーラムにログインできてしまいます。そのため、モデレーターや管理者アカウントに対してはこの招待スタイルの使用を強くお勧めしません。
そのため、この機能を処理するコードは既に存在していますが、実際にそれを利用するには、いくつかのカスタマイズが必要です。