管理者の招待を改善

招待フローを再設計し、1つのステップで誰かを管理者として招待できるようになりました。また、メンバーを招待する際もより分かりやすい体験を提供します。この機能は、**「Enable invite modal with roles」**という今後の変更として、本日利用可能です。

:microscope: フラグを有効にした場合の変更点

招待モーダルは、メンバー / 管理者のトグルスイッチを備えて再設計されました。

  • メンバーを招待:
    招待方法を共有リンク(オプションでメールドメインに制限可能)または特定アドレスに送信されるメール招待から選択します。デフォルトのフォームを簡潔に保つため、二次的なオプション(最大使用回数、説明、有効期限、到着トピック、グループへの追加)は歯車ボタンにまとめられています。

  • 管理者を招待:
    メールアドレスを入力し、作成 & 送信をクリックします。管理者への招待は常に1回限りの使用であり、そのアドレスに制限されます。招待者が受け入れた場合:

    • すぐにモデレーターになり、即座に支援を開始できます
    • 通常の管理者確認メールを受け取ります。確認後、フルアクセスの管理者になります
  • 招待を作成した後、設定された内容の概要が表示され、リンクをコピーまたは共有する準備が整います。招待は作成後、変更できません。

  • 管理者オンボーディングパネルの「コラボレーターを招待」ステップは、管理者タブが事前に選択された状態でこのフローを開きます。

変更前

変更後

:gear: コミュニティで新しい招待フローを有効にする方法

管理エリアの今後の変更ページ(/admin/config/upcoming-changes)に移動します。**「Enable invite modal with roles」の項目を見つけ、「有効にする…」**フィールドを新しい体験にオプトインするように更新します。同じページからいつでもオプトアウトできます。

:mega: ご意見をお聞かせください

皆様にお任せします。このアップデートについてのご意見をお聞かせください。何が好きで、何が嫌いですか?何がうまく機能していて、何が改善できるでしょうか?

「いいね!」 13

なぜ管理者だけを招待して、モデレーターは招待しないのですか? 私には、「招待されたユーザーはサインアップ時にモデレーターになり、招待者がメールを確認すると管理者になります」 という説明が混乱を招きます。つまり、メールを承認しないと単なるモデレーターのままになるということでしょうか? 私は何か勘違いしているかもしれませんが、何かをするには有効なメールが必要なのですよね?

私が作成したこのようなデザインにしないのはなぜでしょうか?

「いいね!」 2

管理者昇格の確認メールをバイパスすることはセキュリティリスクとなるためです。

「いいね!」 3

うん、それは理解できるけど、主に気になってたのは、新しいモデレーターを招待するオプションを提供する代わりに、どうして管理者だけを簡単に招待したいのかってことなんだよ。

「いいね!」 2

良い質問ですね。当初、このフローは、サイト設定と構成を支援するために別の管理者を招待するのが適切である初期のサイトオンボーディング段階に統合できるように設計しました。この管理者招待体験を両当事者にとってより便利で予測可能にするため、モデレーター権限を自動的に付与する機能を拡張することにしました。したがって、メールフローはその決定に伴う副産物です。

モックアップをありがとうございます。同じUIを使用してモデレーターをより簡単に招待できるようにするという提案は良いもので、初期の管理者体験への注目を他にシフトする際に検討する可能性があります。

「いいね!」 4

ああ、わかりました。説明ありがとうございます。文脈が欠けていただけですね。今なら意味が通じます :grin:

「いいね!」 2

このバージョンは非常に気に入っています。なぜなら、両方のケースをカバーしており、多くの場合、モデレーターの方が適切な選択肢になるからです。モデレーターは破壊的な操作への完全なアクセス権を持たないため、それでもなお役に立つことができます(したがって、追加の確認が不要で、プロセスもシンプルになります)。

また、ここで教育的な機会も生まれるかもしれません。例えば、:red_question_mark: リンクを簡単に設置し、両者の権限の違いを説明することができます。管理者が「ああ、実際にはモデレーターで十分だ」と結論づけるたびに、サイトは少しだけ安全になります。

「いいね!」 5

はい、その通りだと思います。

「いいね!」 1