おさむのひと
おさむのひと
管理系のwebhookを持つテーブルを新設して、その上に通報のwebhook機能を載せるような感じで考えている （送信は既存のwebhook送信の仕組みを間借りするようなイメージ）
> 管理系のwebhookを持つテーブル もともとある`webhook`テーブルではなく、システム契機で作動するwebhookを登録しておくための`system_webhook`（仮）を作ろうとしていました。システム契機の場合はユーザIDを持たず、またイベントの種類も既存のwebhookとは異なるため、既存のものと混ぜたくないなという思いから。
> 通報をすぐに開けるURLの発行とフロント側のルーティング 通報一覧画面に対象のIDを引き込めても、バックエンド側との噛み合わせがイマイチで難しいのでいったんオミットする （対象IDをピンポイントで取得する機能が無い）
isModeratorやisAdministratorなフラグがついたロールの扱いも変わりそうな気がしており、それ前提で組まれてる所の洗い出しが大変そう…（設計変更自体は賛成）
@syuilo @kakkokari-gtyih 👀
ちょっと冗長な感じになってしまいますが、 https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/core/RoleService.ts#L280-L281 ↑のあとに`かつ`の判定を追加すれば行けそう…？
運営者向けは https://github.com/misskey-dev/misskey-hub-next/issues/149 で部分的に解消できる可能性あり
（詳しい人にやってもらいたい気持ちがある。僕が着手するときはassigneesを変更します）
〇いま - Misskeyサーバーの作成 - Misskey install shell script v3.0.0 - Docker Composeを使ったMisskey構築 - Kubernetes/TrueNASを使ったMisskey構築 - Misskeyを手動で構築する - Ubuntu版Misskeyインストール方法詳説 〇こうしたい - Misskeyサーバーの作成 - Misskeyの構成（新設） 以下を書きたい - 動作に必要なスペック - 動作に必要なミドルウェア（postgresqlとかredisとか） - 併せて利用すると快適なミドルウェアやサービス（nginxとかmeilisearchとかcloudflareとか）...
ディレクトリ構造は変更無さそう