管理者は、フォーラムの機密部分に誤ってアクセスしてしまう可能性があります。
そのような意図しないアクセスは記録されていません。
管理者は、スーパーパワーによって通常のユーザーエクスペリエンスが見えなくなるため、設定ミスを見逃す可能性があります。
Impersonating a user の機能と同様に、管理者権限を持つユーザーは、必要に応じて管理タスクを実行するために「管理者になる」ことができるべきです。
なりすまし機能とは異なり 、この機能では通常のユーザー権限を回復するためにログアウトする必要はありません。
この機能は以下のことを可能にします。
管理者が通常のユーザーとしてサイトを閲覧できるようにし、他のユーザーの日常的なエクスペリエンスを共有できるようにします。
管理者が誤ってプライベートなフォーラムスペースにアクセスすることを防ぎます。
実際の管理アクセスログにより、そのようなプライベートスペースへの不正アクセスを保護します。
最初の点は、管理者のエクスペリエンスはユーザーエクスペリエンスとは大きく異なるため、管理者はユーザーの問題（たとえば、カテゴリやグループの誤った権限設定に関連するものなど）を認識できない可能性があるため、有用です。
2番目の点は、機密性を必要とするグループの場合に重要になる可能性があります。リンクをクリックすると、管理者が誤って侵入し、機密性を侵害する可能性があります。
3番目の点は、管理者が現在全く責任を負っていない、フォーラムの機密部分への不正アクセスに対して責任を負うことを可能にします。
特権昇格は、実際の管理者アカウントのみが利用できるようにする必要があります。
「管理者」は、追加の信頼レベル（例：レベル5 [^l5]）として考慮される可能性があります。
「通常」モードに戻るには、以前の「信頼レベル」（TL）に戻るだけです。
新しい「管理者パースペクティブ」全体を提供するのではなく、管理者モードはユーザーインターフェースの追加レイヤーを追加する可能性があります。
管理者であることによってのみ機能するリンクをハイライト表示する
管理者であることによってのみアクセスできるカテゴリをハイライト表示する
管理者であることによってのみ表示できるグループメンバーシップをハイライト表示する（例：アクセスが制限されているグループのメンバーである場合、ハイライトは適用されません）
管理者のみが見ることができる情報をハイライト表示する
[^l5]：クリス・マルケル監督の映画『レベル5』（https://en.wikipedia.org/wiki/Level_Five_(film)）への参照。この映画では、プログラマーが亡くなった夫の沖縄戦に関するビデオゲームを完成させ、悲しみを乗り越えようとします。
「いいね！」 3
類似している点は理解できますが、他の議論にはここでの問題に関連する問題があります。
ただし、管理者である場合、通常はアクセスできない機密性の高い会話へのリンクが実際には制限されていることを確認する方法がありません。これは、管理者の役割と参加者の役割が分離されていないことが問題となる可能性のあるケースの 1 つ です（昨日私たちに起こり、このトピックを開始するきっかけとなったものです）。
さらに、Discourse チームは全員が管理者であるという習慣があり、これは水平的な超能力であり、文化として通常の利用と特権的な利用を区別するのに役立ちません。すべてのコミュニティが水平的であるわけではありません。場合によっては、管理者権限を持つ技術担当者はフォーラムのすべてを信頼されるべきではなく、これは例外的なケースではありません。コンピューターシステムは、root がすべてを見たり行ったりできるという形で、最初から構築されてきました。特権には確かに責任が伴いますが、時には善意だけでは不十分です。特に、正常な場合と制限されている場合を区別できない場合はなおさらです。
通常の管理者アカウントと管理者アカウントを処理するための「別のブラウザープロファイルを使用する」という解決策は、特にツールをすぐに使える状態にしておくことに慣れている場合、あまり実用的ではありません。管理者機能が必要になるたびに新しいブラウザーを起動するのは非常に迷惑です（誰もが自分のマシンでアイドル状態のリソースを消費することを好むわけでも、許容できるわけでもありません）。また、詮索好きな目の特権的な [abbr title=“Bastard Operator From Hell”]BOFH[/abbr] 状況が発生するのを防ぐこともできません。
時代は変わりました。ここでは、管理者が機密情報に誤ってアクセスし、他の人々の生活に影響を与えたケースがありましたが、それは本来アクセスすべきではありませんでした。これはプライバシー侵害です。セキュリティの問題です。
潜在的な複雑さは理解していますが、根本的な問題は残っており、何らかの方法で解決されるべきです。私の意見では、コードベースが成熟した今、この問題を再検討し、提案されたアプローチが実行可能かどうかを評価することは有益でしょう。
はい！この種の（立ち入り禁止）問題に関する警告とガードがあると役立ちます。
既存のプラグインについて：
上記すべての理由から、古典的でよく知られた sudo の比喩を使用して、参加者と管理者の間に本当にクリーンな分離を設けたいと考えています。
「いいね！」 1
Ed_S
2024 年 12 月 4 日午後 12:11
4
sudoメカニズム（Windowsではユーザーアカウント制御ダイアログ）は、アカウントが常に管理者権限を持つのではなく、管理者として動作する可能性を持つための良い方法であると同意します。
私のフォーラムの1つでは、管理者ログインを使用し、通常は常に通常のアカウントとしてログインするために「ユーザーのなりすまし」を使用しています。管理者のように行動する必要があるときは、ログアウトして再度ログインします。これは2つのアカウントを意味します。
2つのアカウントの利点の1つは、通常のアカウントで投稿またはコメントするときに、強力で重要な人物として表示されないことです。（場合によっては、管理者のようにコメントすることは、宣言または警察の行動と見なされることがあります。それは読者の文化や期待によって異なります。）
「いいね！」 1
この機能が最終的に実装される（実装されたらぜひ投票してください！）としても、実現までには時間がかかるため、現在2つのアカウントを使用することを検討しています。つまり、既存のアカウントを通常のユーザーアカウントに変換することです。以下にその手順を示します（この投稿は編集するか、最新のドキュメントを維持するためにウィキにするように努めます。注意点も記載します）。
元の Вアカウントの履歴と「フォーラム経験」を失いたくないため、管理者権限を削除する前に慎重に進める必要があります。
ユーザー me （メールアドレス： original-me@email.example ）を想定します。
DISCOURSE_DEVELOPER_EMAILS に含まれる管理者アカウント管理者アカウントのメールアドレスが DISCOURSE_DEVELOPER_EMAILS に含まれている場合、通常の Вアカウントに降格することはできません。
管理者になる新しい Вアカウントを作成します。例： me2 （メールアドレス： original-me+admin@email.example ）。
Вアカウント me から、新しい Вアカウント me2 に管理者権限を付与します。
app.yml （またはデュアルコンテナセットアップを使用している場合は web_only.yml ）を編集し、original-me@email.example を original-me+admin@email.example に置き換えて、コンテナを再構築します。Вアカウント me2 から、元の Вアカウント me を降格させます。
これで、すべての В経験を持つ通常のユーザーアカウント（me）と、新しい管理者専用アカウント（me2）ができました。「事後処理」に進んでください。
これはより簡単です。コンテナを再構築することなく、この Вアカウントを降格させることができます。
管理者になる新しい Вアカウントを作成します。例： me2 （メールアドレス： original-me+admin@email.example ）。
Вアカウント me から、新しい Вアカウント me2 に管理者権限を付与します。
Вアカウント me2 から、元の Вアカウント me を降格させます。
これで、すべての В経験を持つ通常のユーザーアカウント（me）と、新しい管理者専用アカウント（me2）ができました。「事後処理」に進んでください。
以前は、管理者権限を持つ単一の Вアカウントがありました。システム Вの通知を受け取り、フラグを確認し、本来アクセスすべきではない領域（例えば、暗号化されていない場合のプライベート Вメッセージ）や、自分が所属していないグループに制限されているカテゴリにアクセスできました。これらはすべてなくなりました！今後は、以前単一の В/管理者 Вアカウントから行っていたことをすべて行うために、定期的に 管理者 Вアカウントに接続する必要があります（これも、提案されている機能が有用であるもう一つの理由です）。管理者の В通知をリアルタイムで受け取りたい場合は、この規律を身につける必要があります（例：Firefoxのプライベートタブを使用するか、他の Вブラウザで同等の機能を使用します）。
いかなる目的にも使用しないでください 。В中にディスカッションを閲覧しないでください！ Вの信頼レベルの進行に時間がかかり、個人としてアクセスできないリンクをクリックしてしまう可能性が常にあります。
管理者 Вアカウントで何かを読んで、反応したくなった場合は、通常のユーザータブに切り替えて元の Вにアクセスするか、通常のユーザーがそのセクションにアクセスできない場合は、すぐに忘れてください（もちろん、管理者として反応すべき場合を除きます）。
アバターを変更して、管理者 Вアカウントと通常のユーザー Вアカウントを絶対に混同しない ようにしてください。プロフィールを非表示にします。背景画像やテーマを変更したり、名前に「ADMIN」や「THIS ACCOUNT DOES NOT POST」のようなものを追加したりします。とにかく、管理者 Вアカウントで投稿したいと思わないようにしてください。
TODO：このセクションを詳しく説明する
管理者 Вアカウントで、すべての В通知をメールでミュートするように設定する必要があります（ Вタブを開き続けることを避けるために、そのような通知を受け取りたい場合を除きます）。そして、 Вの通知が個人用なのか、管理者 Вとしての Вなのかを明確に区別できる必要があります。
フラグや重要な Вをキャッチするために、デスクトップで通知を受け取りたいと思うでしょう。
staff カテゴリとウィスパーはどうすればよいですか？はい、管理者と通常のユーザー Вの2つの Вアカウントを使用することには、もう一つ複雑な問題があります。フォーラムで管理者として Вする必要がある場合もあります。これはおそらく避けられません。精神分裂症にならないようにし、staff の介入をできる限り最小限に抑えるようにしてください。この困難な問題に対処するためのあなたの戦術を報告し、この機能を実装するために Вチーム全体を動機付けてください。
Вと管理のクリーンな分離（ある程度）
通常 Вアカウントから間違いを犯すことはありません
すべての管理者 Вは適切に記録されます
Вとして、他の Вと同じようにフォーラムを体験できるため、権限の問題を簡単に発見できます
管理者として投稿してしまったが、自分自身として投稿するつもりだった場合、 Вを別の Вアカウントに変更できます（ただし、これは2つの Вアカウントを持つ意味を薄れさせます）。
管理者は通常のユーザーまたはTL4になりますが、「管理者モード」をオンにして特別な管理者機能を使用できますか？
「いいね！」 2
Ed_S
2024 年 12 月 5 日午後 4:31
7
それは興味深いメモですね。コンテンツなしで、通知の配信を制御するグループを許可するようにギャップを埋める方法はありますか？「フラグが付けられた投稿があります」「メッセージが待機中です」「インストールが最新ではありません」
「いいね！」 1
Ed_S
2024 年 12 月 5 日午後 4:34
8
アイデアは次のとおりです。管理者ロールは、公開カテゴリまたはスレッドに投稿できず、投稿に「いいね！」することもできません。
「いいね！」 2
Ar_D
2024 年 12 月 5 日午後 6:14
9
また、通常のユーザーのようにアカウントを無視することもできます。管理者が無視したい場合にのみ、管理者から必要な更新を取得します。
「いいね！」 1
まだテストされていません：これはすべて理論的なもので、私の思いつきです。