misskey-dev
管理者アカウントと利用者アカウントを分離する
Summary
現在どちらも同じ User モデルとして表現されているが、管理者(モデレーター)アカウントを別モデルに分離する
Purpose
- サーバーの管理者、もしくはモデレーターが必ずミスキストであるとは限らない
- 「Misskeyは利用しないモデレーション専門のスタッフ」を用意するシチュエーションは普通に考えられるが、そのようなスタッフに対してもMisskey利用者としてのアカウントが作成されるのは無駄だし誤操作・情報漏洩等のリスクがありトラブルの原因になる
- https://github.com/misskey-dev/misskey/issues/13740 のような問題の解決
- モデレーターアカウントは自分でアカウントを削除できたりするが、そのようなアカウントが削除されるとログが追いにくくなる
- 分離されていれば、「モデレーターアカウントは管理者アカウントからしか削除できない」のような設計も可能になる
- モデレーターアカウントをユーザーアカウントに紐付ける機能を実装すれば今まで通りシームレスなモデレーションが行える
cons
- 実装がめんどくさい
- admin APIに互換性が無くなる可能性がある
Do you want to implement this feature yourself?
- [ ] Yes, I will implement this by myself and send a pull request
isModeratorやisAdministratorなフラグがついたロールの扱いも変わりそうな気がしており、それ前提で組まれてる所の洗い出しが大変そう…（設計変更自体は賛成）
isModeratorやisAdministratorなフラグがついたロールの扱いも変わりそう
そこはアカウント紐付け機能が実装されれば変わらずにできそう
admin APIに互換性が無くなる可能性がある
そこはアカウント紐付け機能が実装されれば変わらずにできそう
アカウント紐づけが実装されていればisModeratorやisAdministratorを残すことはできるという前提に立てばadminAPIの互換性維持もできそうなイメージ
これはここでの私のコメントに関連していると思いますが、理想的には、トークンですべてを実行できるのフールスコープセッションと想定するのではなく、UI は制限されたスコープのセッション (ここではアクティブな投稿ではなくモデレーションに制限されているなど) に適応するほうがいいと思います。
https://github.com/misskey-dev/misskey/issues/15053#issuecomment-2496550746
例えば、スコープがユーザー/トークンに付与されていない場合、フロントエンドは投稿ボタンを非表示にします。
前提として、複数の課題に対する共通の解としての管理者アカウント分離と理解しています。
admin APIに互換性が無くなる可能性がある
そこはアカウント紐付け機能が実装されれば変わらずにできそう
アカウント紐づけが実装されていればisModeratorやisAdministratorを残すことはできるという前提に立てばadminAPIの互換性維持もできそうなイメージ
これを考えると、User モデルの分離というよりも、モデレーターとしての別名を与えるようなイメージになりそうです。 その場合、「Misskeyは利用しないモデレーション専門のスタッフ」に結局User モデルを付けることになりそうです。 もしくは、「Misskeyは利用しないモデレーション専門のスタッフを分離」するということを前提にUserモデルを使わないようにすると、UserProfileの簡易版を別に実装することになりそうな気がします。
これらの事を考えると、以下の方法が簡単に実現できそうに思いました。
- ModeratorProfileモデルの追加(moderatorIdとuserId、モデレーターとしての名前を持つ)、user削除で削除しない
- モデレーター用のロールポリシーを追加、拡充
- モデレーションしかできないようにするロールポリシーの追加
- モデログへの記録はModeratorProfileとリレーションする
（「〜そう」ばかりですみません）